andrey

Путь к Файлу: /4 курс / PIZB-10_05_01_14 / ПроектИС_Жданов_ПИЗб-10 / Черемных_Моделирование и анализ систем_IDEF-технологии_практикум.pdf

Ознакомиться или скачать весь учебный материал данного пользователя
Скачиваний:   39
Пользователь:   andrey
Добавлен:   05.01.2015
Размер:   6.9 МБ
СКАЧАТЬ

Наверх страницы

Содержимое файла:

ПГМКЛАДНЫ! ИНФОРМАЦИОННЫ! ТЕХНОЛОГИИ »ГИИ Л||^ св. Черемных И, О, Семенов В. СРучкин Моделирование и анализ сиоем. праюикум Москва 'Финансы и статистика" Сери я "Прикладные информационные технологии" Главный редактор серии доктор технических наук, профессор СВ. Черемных РЕЦЕНЗЕНТ доктор технических наук, профессор В.А. Бывшее Черемных СВ. кум / С.В.Черемных, И.О. Семенов, B.C. Ручкин. - М.: формационные технологии). практикум по системному структурному анализу на основе пакета стандартов моделирования IDEF предназначен для формирования практических навыков их использования для построения моделей экономических систем. Первая часть прак­ Вторая часть представляет собой комплект заданий на базе этого комплекса для аудиторной и самостоятельной работы слушателей. Для студентов, аспирантов, преподавателей вузов, специалистов-менеджеров всех уровней, слушателей, получающих второе высшее образование. к читателю Структурный системны анализ как практический метод служит инструментом человеческого разума для анализа ситуаций тысячеле­ тия (с момента возникновения и разума, и ситуаций). Научный подход в этой области сложился сравнительно недавно. В настоящее время под этим термином понимается «метод исследования системы, кото­ рый начинается с ее общего обзора и затем детализируется, приобре­ Два базовых принципа заложены в этом определении, а именно: прин­ цип «разделяй и властвуй» и принцип так называемого «иерархиче­ ского упорядочивания». Понимание этих принципов, знание предмет­ ной области и общей логики научного анализа вполне достаточно для решения прикладных задач, хотя точного определения структурного системного анализа к большой досаде поклонников «чистой науки» и не существует. В истории науки и техники такое случалось нередко. Отдавая должное замечательным достижениям математики, мы, согласно уро­ кам истории, в постановке задач и выборе методов их решения долж­ ны отталкиваться от предметной области, следуя классическому афо­ ризму: ученые делают то, что можно, но так, как нужно, инженеры — наоборот: то, что нужно, но уж как получится. И в этом нет пугающего антагонизма: грамотно и своевременно решенная инженерная или экономическая задача со временем часто получает изящное математи­ ческое оформление. «Почему мы должны отказываться от обеда лишь на том основа­ нии, что не полностью понимаем процессы пищеварения?» — печаль­ инженер, в дискуссии с не менее блестящими математиками по пово­ ду острой критики недостаточной обоснованности своего метода (операционного исчисления в теории дифференциальных уравнений). При этом Хевисайд, опираясь на свой метод, не реагируя на критику, решал одну за другой важнейшие практические задачи из области электротехники. В наши дни метод операционного исчисление чита­ ется в технических вузах как самостоятельная математическая дисци­ плина, параллельно с ней — электротехника, где излагаемый в мате­ матическом курсе метод является одним из ключевых в расчете так называемых линейных цепей. Мы тоже не будем отказываться от нашего «исчисления». Думает­ ся, наличие международного стандарта на излагаемые технологии — весомый для любого специалиста аргумент в решении вопроса, ис- пользовать или не использовать данную технологи в соответствую­ щей ситуации. Обращаясь непосредственно к содержанию этой работы, прежде всего необходимо уточнить некоторые детали, касающиеся термина «системный структурный анализ». Три идеи, лежащие в нашем пони­ • идея разбиения исследуемого процесса на функциональные бло­ ки — подпроцессы исходя из ряда принципов, например «опреде­ ленности» (выход каждого блока должен быть ясно понимаем независимо от сложности происходящего процесса), «единствен­ ности» и т.д.; • идея иерархии, означающая возможность детализации (декомпо­ зиции) любых нужных нам процессов, реализованная в виде так называемых «иерархических структур»; • идея использования графических нотаций с возможностью «тек­ стового» разъясняющего дополнения. Предлагаемая книга представляет собой практикум по технологии структурного анализа в варианте, базирующемся на хорошо извест­ ных специалистам методологиях, позволяющих анализировать про­ цессы (в том числе и бизнес-процессы) с трех ключевых точек зрения одновременно — IDEFO (Integration Definition for Function Modeling), • IDEFO-технология структурного анализа и проектирования. Это (SoftTech, Inc.) и называвшийся в исходном своем виде SADT (Structured Analysis and Design Technique). Согласно этой техноло­ гии анализируемый процесс представляется в виде совокупности множества взаимосвязанных действий, работ (Activities), которые взаимодействуют между собой на основе определенных правил (Control), с учетом потребляемых информационных, человеческих и производственных ресурсов (Mechanism), имеющих четко опре­ деленный вход (Input) и не менее четко определенный выход (Output); • ГОЕРЗ-технология сбора данных, необходимых для проведения структурного анализа системы, дополняющая технологию IDEFO. С помощью этой технологии мы имеем возможность уточнить картину процесса, привлекая внимание аналитика к очередности выполнения функций и бизнес-процессов в целом. Логика этой технологии позволяет строить и анализировать альтернативные сценарии развития изучаемых бизнес-процессов (модели типа "Что — если"?); • DFD (Data Flow Diagram) — структурный анализ потоков данных. Диафаммы DFD позволяют описать процесс обмена информаци- ей между элементами изучаемой системы. DFD отображает источ­ ники и адресаты данных, идентифицирует процессы и групп дан­ ных, связывающие в потоки одну функцию с другой, а также, что важно, определяет накопители (хранилища) данных, которые ис­ пользуются в исследуемом процессе. Упомянутые методологии имеют мощную компьютерную под­ что превращает совокупность упомянутых методологий в единый ин­ струментальный метод структурного системного анализа, примени­ мый практически к любым видам «активности» человека. Далеко не случайно, кстати, что основной блок технологии IDEFO в оригинале назван «Activity». Важно для системы образования также и то, что обсуждаемые ме­ тодологии относятся к так называемым «открытым» стандартам, в от­ личие от «корпоративных» (ARJS, ORACLE и многих других). Ограничений на использование технологий IDEF-BPWin в настоя­ щее время не наблюдается. Поэтому из технологии профессионально­ го использования они за последние годы шаг за шагом превращаются в технологии общего пользования. Подготовленные на основе этого подхода специалисты, как представляется, составляют активный ре­ зерв аналитиков и (или) менеджеров предприятий, организаций, фирм, призванных играть ключевые роли в их развитии, резерв, гото­ вый от имени своей фирмы в тесном контакте с профессиональными консалтинговыми компаниями решать сложнейшие проблемы корпо­ ративного «инжиниринга» и «реинжиниринга». Дополнительная га­ рантия успеха состоит в том, что и те, и другие имеют возможность общаться на одном с ними языке — языке моделирования IDEF. В этом своем качестве (в условиях вуза) IDEF-BPWin-технологии полезны не только и не столько для изучения тонкостей анализа пред­ метной области (откуда у будущих еще выпускников знание этих тон­ костей!), сколько для формирования современного менталитета буду­ щих выпускников. Проще говоря, они учат думать правильно, процессно. Учить думать — вообще-то задача всего образования. Уверен­ ность в том, что технологии структурного анализа могут внести свой серьезный вклад в решение этой задачи дает сама природа IDEF- BPWin-технологии. Поясним этот тезис, используя музыкальную базисных понятиях, на которые опирается обсуждаемая триединая технология: цель (анализа); точка зрения (аналитика, менеджера, владельца процесса и т.д.); функциональный блок («активность»); интерфейсная дуга; декомпозиция; глоссарий (словарь); диалог «ана­ литик — эксперт». Здесь, как видно, представлены и человеческие фактор (цель, точка зрения, глоссарий, диалог) и формализуемые факторы (функ­ циональный блок, интерфейсная дуга, декомпозиция), подчиняющие­ ся семантике и синтаксису языка, каковым, в сущности, является изла­ гаемая «структурная» технология. В такой интерпретации IDEF-BPWin-технологии предстают в ис­ торическом плане как реализация мечты специалистов по человеко- тех лет инструментальные методы поддержки принятия решений, ко­ торые в идеале способны были бы соединить в едином порыве коня и трепетную лань — жесткость машинной логики и изменчивость (час­ то вредящую делу) человеческого настроения. Отмеченная выше открытость стандартов IDEF создает очевидное (конкурентное!) преимущество использования этих технологий в об­ разовательной сфере. Вспомним открытость стандартов IBM PC — основную причину взрыва активности предприятий, производящих персональные компьютеры в прошедшие два десятилетия. Так что у нас есть все основания ожидать если не взрыва, то резкого увеличения активности в вопросах внедрения «открытых» IDEF-BPWin-техноло- гий в жизнь в ближайшее время. Представляемая книга состоит из двух частей — теоретической и практической. Первая часть содержит необходимые сведения по тех­ плект заданий на базе этого комплекса. Принята структура изложения, отвечающая принципу "от простого к сложному". Компьютерная поддержка практикума, о чем говорилось выше, — программный В общем, успехов Вам, дорогой читатель. Вас ожидает путешест­ вие в новый мир — мир новейших информационных компьютерных технологий, специализированную информационную среду, работая в которой. Вы сможете посмотреть на свою активность другими глаза­ ми и сделать весь процесс принятия решений в своей сфере гораздо более обоснованным. СВ. Черемных, доктор технических наук профессор Финансовой академии при Правительстве РФ Предисловие в настоящее время вс большую популярность приобретают ин­ женерные методы реорганизации предприятий на основе современ­ ных информационных технологий. Понятия «бизнес-процессы», «процессно-стоимостной подход», «структурный системный анализ», «функциональное моделирование», «информационное моделирова­ ние», «реинжиниринг» и многие другие, с ними связанные, уверенно входят в лексикон аналитиков всех уровней. Соответственно расши­ ряется спектр компьютеризованных инструментальных методов ана­ лиза экономических процессов и бизнес-процессов в частности. Перечень специальностей, где активно используются новейшие технологии, первоначально ориентированный в основном на специ­ альности «Информационные системы в экономике», «Менеджмент», постоянно расширяется. В этом списке в данный момент уже нашли себе место такие специальности, как «Бухгалтерский учет и аудит», «Финансы и кредит», «Мировая экономика», «Антикризисное управ­ ление», «Маркетинг» и т.д. В Финансовой академии при Правительстве Российской Федера­ ции создан новый институт «Математические методы и антикризис­ ное управление» для подготовки специалистов квалификации «эконо­ мист-математик». Разработаны требования к рабочим программам в рамках единой концепции формирования у слушателей навыков при­ менения инструментальных методов структурного системного анали­ за экономических процессов, включая аспирантские и магистерские ментальные методы в экономике». Соответствующие рабочие программы выглядят, конечно, по-раз­ ному в соответствии с различием требований для разных категорий слушателей: студентов, аспирантов, магистрантов или слушателей систем дополнительного образования. В зависимости от специфики используются какой-либо из блоков общего направления либо их ком­ бинации (см. таблицу). Количество часов, выделяемых на практику, составляет около половины общего количества для каждого блока Представляемое учебное пособие (практикум), как видно из таб­ лицы, имеет свою нишу в учебно-методическом комплексе. Техноло- гия его использовани зависит о ситуации: в аудиторной работе он служит естественной поддержко лекционно части дисциплины, а в процессе самостоятельной работы слушателей — руководством к приобретению соответствующих навыков моделирования. Структура программ дисциплин по инструментальным методам Наименование дисциплины Структурный анализ бизнес- процессов Информационное моделирование бизнес-процессов Реинжиниринг и оптимизация бизнес-процессов Методо­ логичес­ кая ос­ нова IDEFO, DFD, IDEFI, IDEF, Design/ IDEF Инструмен­ тальная под­ держка Design/IDEF, Design/ IDEF Объем Всего Лек­ ции Прак­ тикум Форма итогового контроля Реферат, зачет Зачет Курсовая работа, полном объеме рекомендуется использовать набор рабочих файлов BPWin, размещенных на сайте Финансовой академии www.fa.ru. качестве вспомогательного средства для получения практических на­ выков работы в среде моделирования IDEFO. Авторы считают своим приятным долгом выразить благодарность сотрудникам фирмы Interface, дистрибьютеру программного продук­ процесс Финансовой академии при Правительстве Российской Феде­ рации. ГЛАВА МЕТОДОЛОГИЯ ОПИСАНИЯ является обеспечение структурированного метода, используя кото­ рый эксперт в предметной области может описать положение вещей как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к про­ цессу. бующихся для проведения структурного анализа системы. В отличие не имеет жестких синтаксических или семантических офаничений, делающих неудобным описание неполных или нецелостных систем. Кроме того, автор модели (системный аналитик) избавлен от необхо­ димости смешивать свои собственные предположения о функциони­ ровании системы с экспертными утверждениями в целях заполнения &к Проверить баланс на счете Напечатать и выдать чек Л Проверить статус клиента Проверить данные ^^ чека сумму наличными ектирования бизнес-процессов. ГОЕРЗ-моделирование органично до­ полняет традиционное моделирование с использованием стандарта IDEFO. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируе­ мых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуата­ ционных качеств разрабатываемой системы, более подробно методы имитационного анализа будут рассмотрены позднее. процесса, который выделяет последовательность действий или под­ процессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является подбор подходящего наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных сущест­ вительных. Например, "Обработать заказ клиента" или "Применить новый дизайн" — вполне подходящие названия сценариев. Точка зрения для большинства моделей должна быть явным обра­ зом документирована. Обычно это название набора должностных обя­ занностей человека, являющегося источником информации о модели­ руемом процессе. Для системного аналитика также важно понимание цели моде­ лирования — набора вопросов, ответами на которые будет служить модель, границ моделирования (какие части системы войдут в модель а какие не будут в ней отображены) и целевой аудитории (для кого разрабатывается модель). Как и в любой рассматриваемой в этой книге технологии модели­ является диаграмма. Взаимная организация диаграмм внутри модели последующего опубликования или рецензирования, что является вполне обычной практикой при проектировании новых систем. В этом случае системный аналитик должен позаботиться о таком информаци­ онном наполнении диаграмм, чтобы каждая из них была самодоста­ точной и в то же время понятной читателю. Аналогично другим технологиям моделрфования действие, или в в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каж­ дому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах Обработать заказ клиента . Название действия Номер действия Номер родительского действия Связи выделяют существенные взаимоотношения между дейст­ стрелка может начинаться или заканчиваться на любой стороне блока, ются слева направо таким образом, что стрелки начинаются на правой возможных типа связей. РГзображение ••"'•'•"•'" " ^ • Название Временное пред­ шествование (Temporal prece­ dence) Объектный поток (Object flow) Нечеткое отноше­ ние (Relationship) Назначение Исходное действие должно завершиться прежде, чем конечное действие сможет | начаться Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное дей­ ствие должно завершиться прежде, чем конечное действие сможет начаться Вид взаимодействия между исходным и конечным действиями задается анали­ тиком отдельно для каждого слз^ая ис­ пользования такого отношения | Связь типа "Временное предшествование". Как видно из назва­ ния, связи этого типа отражают, что исходное действие должно пол­ ностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы че­ ловеку, просматривающему модель, была понятна причина ее появле­ ния. Во многих случаях завершение одного действия инициирует на­ автор должен принять рекомендации рецензентов, прежде чем начать вносить соответствующие изменения в работу. Принять рекомендации Принятие исправлений Внести исправления Связь типа "Объектный поток". Одной из наиболее часто встре­ чающихся причин использования связи типа "объектный поток" со­ стоит в том, что некоторый объект, являющийся результатом выпол­ нения исходного действия, необходим для выполнения конечного действия. Такая связь отличается от связи временного предшествова­ ния двойным концом обозначающей ее стрелки. Наименования по­ токовых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования. Это означает, что порождающее Получить счет на оплату услуг Счет к оплате Произвести оллату объектную связь исходное действие должно завершиться, прежде чем приведенном примере счет на оплату услуг является результатом вы­ Связь типа '''Нечеткое отношение". Связи этого типа использу­ ются для выделения отношений между действиями, которые невоз­ можно описать с использованием предшественных или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа "Нечеткое отношение" сами по себе не пред­ полагают никаких ограничений. Одно из применений нечетких от­ ношений — отображение взаимоотношений между параллельно цесса запуска бензопилы с водяным охлаждением и нечеткое отноше­ ние между действиями "Запустить двигатель" и "Запустить водяной насос". Название стрелки может быть использовано для описания природы отношения, более подробное объяснение может быть приве­ дено в виде отдельной ссылки. Запустить двигатель Запустить водяной насос для предотвращения перегрузки электрической цепи Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например для описа­ ния альтернативных вариантов временного предшествования. Обра­ связь. В соответствии с рисунком внесение исправлений в работу на­ чинается ПОСЛЕ принятия всех замечаний от рецензентов. Время лений начинается по мере получения замечаний от рецензентов, т.е. до непосредственного окончания действия по принятию замечаний. Принять рекомендации рецензентов Принятие исправлений Внести исправления I шкала. Время Отметим еще раз необходимость четкого документирования вре­ менных ограничений между действиями, соединенными нечетким от­ ношением. В качестве примера рассмотрим еще одну временную шка­ Время начато после получения первых замечаний, однако будет закончено ПЕРЕД тем, как все замечания от рецензентов будут получены и обра­ ботаны. Оба рассмотренных выше варианта временной альтернативной шкалы могут иметь место в реальности, поэтому корректная интер­ претация нечеткого отношения должна быть документирована в мо­ дели. Важно отметить, что корректность в этом случае означает именно интерпретацию, которая в точности отображает документи­ руемую ситуацию, а не интерпретацию, более эффективную для рабо­ ты системы, с точки зрения аналитика. Завершение одного действия может инициировать начало выпол­ нения сразу нескольких других действий, или, наоборот, определенное действие может требовать завершения нескольких других действий для начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса. • Разворачивающие соединения используются для разбиения пото­ ка. Завершение одного действия вызывает начало выполнения не­ скольких других. • Сворачивающие соединения объединяют потоки. Завершение од­ ного или нескольких действий вызывает начало выполнения толь­ ко одного другого действия. Графическое обозначение & X Название Соединение "И" Соединение "Эксклюзив­ ное ИЛИ" Вид Разворачивающее Сворачивающее Разворачивающее Правила инициации Каждое конечное действие обязательно инициируется Каждое исходное действие обязательно должно завер­ шиться Одно и только одно конечное действие инициируется Продолжение Графическое X Название Соединение "Эксклюзив­ ное ИЛИ" Соединение "ИЛИ" Вид Сворачивающее Разворачивающее Сворачивающее Правила инициации Одно и только одно исходное действие должно завершить- ся Одно (или более) конечное действие инициируется Одно (или более) исходное действие должно завершить­ Примеры разворачивающих и сворачивающих соединений приве­ |о • ^ • Проверить данные чека Подготовить сумму наличными " • ^—И / М |о| "И"-соединения. Соединения этого типа инициируют выполне­ ние всех своих конечных действий. Все действия, присоединенные к сворачивающему "И"-соединению, должны завершиться, прежде чем обнаружения пожара инициируются включение пожарной сигнализа­ ции, вызов пожарной охраны и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных дей­ ствия завершены. Соединение "Эксклюзивное ИЛИ". Вне зависимости от количе­ ства действий, прицепленных к сворачивающему или разворачиваю­ щему соединению "Эксклюзивное ИЛИ", инициировано будет только одно из них, и поэтому только одно из них будет завершено перед тем, как любое действие, следующее за сворачивающим соединением "Эксклюзивное ИЛИ", сможет начаться. Обнаружение пожара — М | & ^ Л л^- " •- пожарную [ к тушению L —м |& ,)? —^ Сделать запись в журнале дежурств Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения, как показано отображения того факта, что студент не может одновременно быть на­ правлен на лекции по двум разным курсам. проверить заявку студента li'i' " т •• Кредит |х Л Направить по кредиту Аудит Направить на лекции по аудиту J |х Записать результат экзамена Соединение "ИЛИ". Соединения этого типа предназначены для описания ситуаций, которые не могут быть описаны двумя предьщу- щими типами соединений. Аналогично связи нечеткого отношения соединение "ИЛИ" в основном определяется и описывается непосред- тивировать проверку данных чека и (или) проверку суммы наличных. Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных — при оплате наличными. И то, и другое действие инициируется при частичной оплате чеком и частичной — наличными. |о ) f—^ ^^—• данные чека Проверить сумму наличных ' ^—^ |о Синхронные и асинхронные соединения. В рассмотренных при­ мерах связей "И" и "ИЛИ" мы не затрагивали отношений между нача­ лом и окончанием действий, инициируемых разворачивающими со­ единениями. Все действия в этих примерах выполнялись асинхронно, т.е. они не должны были начинать выполняться одновременно. Одна­ ко есть случаи, когда время начала или окончания параллельно выпол­ няемых действий должно быть одинаковым, т.е. действия должны вы­ полняться синхронно. Для моделирования такого поведения системы синхронных соединений. Графическое обозначение {& |о Тип И ИЛИ Вид Разворачивающее Сворачивающее Разворачивающее Правила инициации Все действия начнутся одно­ временно Все действия закончатся одно­ временно Может быть, несколько дейст­ вий начнутся одновременно Продолэюение Графическое |о |х Тип ИЛИ Эксклюзив­ ное ИЛИ Вид Сворачивающее Разворачивающее Сворачивающее Правила инициации Можеа быть, несколько дейст­ вий закончатся одновременно Одновременное начало дейст­ вий невозможно | Одновременное окончание действий невозможно | Синхронное соединение обозначается двумя вертикальными ли­ ниями внутри обозначающего его прямоугольника в отличие от одной вертикальной линии в асинхронном соединении. Во многих спортивных состязаниях выстрел стартового пистоле­ та, запуск секундомера и начало состязания должны произойти одно­ временно. В противном случае состязание будет нечестным. пользованием синхронного соединения. Начать состязания |& ч Выстрелить из стартового пистолета Запустить секундомер Начать забег Заметим, что синхронное разворачивающее соединение не обяза­ тельно должно иметь парное себе сворачивающее соединение. Дейст­ вительно, начинающиеся одновременно действия вовсе не обязаны оканчиваться одновременно, как это видно из примера с состязания­ ми. Также возможны ситуации синхронного окончания асинхронно начавшихся действий. Парность соединений. Все соединения на диаграммах должны быть парными, из чего следует, чт любое разворачивающе соедине­ ние имеет парное себе сворачивающее. Однако типы соединений во­ "И"-соединение имеет парное сворачивающее "ИЛИ"-соединение. Интерпретация соединения Л аналогична случаю, показанному на сле включения пожарной сигнализации и (или) вызова пожарных и (или) начала тушения производится запись в журнал. Обнаружение пожара —м В л Включить пожарную сигнализацию Приступить к тушению пожара Сделать запись в журнале дежурства Комбинации соединений. Соединения могут комбинироваться "^"^Lffk х_ — • ции соединени следует использовать с осторожностью, поскольку перегруженные ветвлением диаграммы могут оказаться сложными для восприятия. Указатели — это специальные символы, которые ссылаются на другие разделы описания процесса. Они выносятся на диаграмму для привлечения внимания читателя к каким-либо важным аспектам мо­ дели. ОБЪЕКТ (OBJECT) ССЫЛКА (GOTO) ЕДИНИЦА ДЕЙСТВИЯ (Unit of Behavior — UOB) ЗАМЕТКА (NOTE) УТОЧНЕНИЕ ! (Elaboration — ELAB) Назначение Для описания того, что в действии принимает внимания объект Для реализации цикличности выполнения дей­ ствий. Указатель ССЫЛКА может относиться и к соединению Для помещения на диаграмму дополнительного экземпляра уже существующего действия без зацикливания. Например, если действие "Подсчет наличных" выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указате­ Для документирования любой важной информа­ ции общего характера, относящейся к изображен­ ному на диаграммах. В этом смысле ССЫЛКА служит альтернативой методу помещения тек­ стовых заметок непосредственно на диаграммах Для уточнения или более подробного описания изображенного на диаграмме. Указатели УТОЧ­ НЕНИЕ обычно используются для описания ло­ гики ветвления у соединений | Указатель изображается на диаграмме в виде прямоугольника, по­ хожего на изображение действия. Имя указателя обычно включает его изображен указатель типа ОБЪЕКТ. Объект/Пилот Провести посадку ОБЪЕКТ Объект/Пилот ОБЪЕКТ ссылается на действие модели отношения между действием и объектом. на составляющие, для более детального анализа. Декомпозировать действие можно несколько раз. Это позволяет документировать аль­ тернативные потоки процесса в одной модели. Для корректной идентификации действий в модели с множествен­ ными декомпозициями схема нумерации действий расширяется и на­ ряду с номерами действия и его родителя включает в себя порядковый вия. бизнес-процессов в этом подразделе мы рассмотрим построение ГОЕРЗ-диаграммы на основе выраженного в текстовом виде описания процесса. Пред­ полагается, что в построении диаграммы принимают участие ее автор (в основном как системный аналитик) и один или несколько экспер­ тов предметной области, которые будут представлять нам описание процесса. моделирования, точки зрения Перед тем как попросить экспертов предметной области подгото­ вить описание моделируемого процесса, должны быть документиро­ ваны границы моделирования, чтобы экспертам была понятна необхо­ димая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от обычной точки зрения для эксперта, это должно быть ясно и аккуратно описано. Вполне возможно, что эксперты не смогут сделать приемлемое описание без применения формального опроса автором модели. В та­ ком случае автор должен заранее приготовить набор вопросов таким же образом, как журналист заранее подготавливает вопросы для ин­ тервью. Результатом работы экспертов обычно является текстовый доку­ мент, описывающий интересующий аналитика круг вопросов. В до­ полнение к нему может иметься письменная документация, позволяю­ щая пролить свет на природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она ана­ лизируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих в про­ цессе. В некоторых случаях возможно создание графической модели процесса в присутствии экспертов. Такая модель также может быть разработана после сбора всей необходимой информации, что позволя­ ет не отнимать время экспертов на детали форматирования получаю­ щихся диаграмм. вирования номеров действий в модели. Каждому аналитику выделяет­ ся уникальный диапазон номеров действий, что обеспечивает их неза­ каждому аналитику большими блоками. В этом примере Иван исчер­ пал данный ему вначале диапазон номеров и дополнительно получил второй. Аналитик Иван Петр Николай Иван Если модель создается после проведения интервью, аналитик дол­ жен принять решения по построению иерархии участвующих в моде­ ли диаграмм, например, насколько подробно будет детализироваться каждая отдельно взятая диаграмма. Если последовательность или па­ раллельность выполнения действий окончательно не ясна, эксперты могут быть опрошены вторично (возможно, с использованием черно­ вых вариантов незаконченных диаграмм) для получения недостаю­ щей информации. Важно, однако, различать предполагаемую (появ­ ляющуюся из-за недостатка информации о связях) и явную (ясно указанную в описании эксперта) параллельности. • * * нужен для описания положения вещей как упорядоченной последова­ тельности событий с одновременным описанием объектов, имеющих лен для сбора данных, требующихся для проведения структурного стоимостного анализа поведения моделируемой системы. ГЛАВА МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEFO Методология функционального моделирования IDEFO — это тех­ нология описания системы в целом как множества взаимозависимых действий, или функций. Важно отметить функциональную направ­ ленность IDEFO — функции системы исследуются независимо от объ­ ектов, которые обеспечивают их выполнение. "Функциональная" точ­ ка зрения позволяет четко отделить аспекты назначения системы от повой диаграммы IDEFO. Данные о поступлениях Начисления Отсрочки Данные о налого- плательщиках Обработка данных о поступлениях Методо­ логия Ведение лицевых карточек налогоплательщиков - юридических лиц Карточки лицевых счетов Прочие документы Подготовка отчетности, анализ и прогнозирование Отчет­ ность Наиболее часто IDEFO применяется как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах разработки проекта, до "как есть". Результаты IDEFO анализа могут применяться при прове­ потоков данных. моделейIDEFO IDEFO сочетает в себе небольшую по объему графическую нота­ цию (она содержит только два обозначения: блоки и стрелки) со стро­ гими и четко определенными рекомендациями, в совокупности пред­ назначенными для построения качественной и понятной модели системы. Методология IDEFO в некоторой степени напоминает рекоменда­ ции, существующие в книгоиздательском деле, часто набор напеча­ танных моделей IDEFO организуется в брошюру (называемую в тер­ минах IDEFO комплект), имеющую содержание, глоссарий и другие элементы, характерные для законченной книги. Первый шаг при построении модели IDEFO заключается в опреде­ лении назначения модели — набора вопросов, на которые должна от­ вечать модель. Набор вопросов можно сравнить с предисловием, в ко­ тором раскрывается назначение книги. Границы моделирования предназначены для обозначения ширины охвата предметной области и глубины детализации и являются логи­ ческим продолжением уже определенного назначения модели. Как читающий модель, так и непосредственно ее автор должны понимать степень детальности ответов на поставленные в назначении модели вопросы. Следующим шагом указывается предполагаемая целевая аудито­ рия, для нужд которой создается модель. Зачастую от выбора целевой аудитории зависит уровень детализации, с которым должна созда­ ваться модель. Перед построением модели необходимо иметь пред­ ставление о том, какие сведения о предмете моделирования уже известны, какие дополнительные материалы и (или) техническая документация для понимания модели мог)гг быть необходимы целе­ вой аудитории, какие язык и стиль изложения являются наиболее подходящими. Под точкой зрения понимается перспектива, с которой наблюда­ лась система при построении модели. Точка зрения выбирается таким образом, чтобы учесть уже обозначенные границы моделирования и назначение модели. Однажды выбранная точка зрени остаетс неиз­ менной для всех элементов модели. При необходимост могут быть созданы другие модели, отображающие систему с других точек зре­ ния. Вот несколько примеров точек зрения при построении моделей: клиент, поставщик, владелец, редактор. Действие, обычно в IDEFO называемое функцией, обрабатывает или переводит входные параметры (сырье, информацию и т.п.) в вы­ ходные. Поскольку модели IDEFO представляют систему как множе­ ство иерархических (вложенных) функций, в первую очередь должна быть определена функция, описывающая систему в целом — контек­ стная функция. Функции изображаются на диаграммах как поимено­ ванные прямоугольники, или функциональные блоки. Имена функ­ ций в IDEFO подбираются по сходным правилам с именами действий в тельных. Важно подбирать имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования. Пример функционального блока приведен Выше мы определяли IDEFO модели как иерархическое множество вложенных бло­ ков. Любой блок может быть декомпозиро- **"^- ^-^l Функциональный ^ ^ ^ блок IDEFO ван на составляющие его блоки. Декомпо­ зицию часто ассоциируют с моделировани­ ем "сверху вниз", однако это не совсем верно. Функциональную де­ композицию корректнее определять как моделирование "снаружи во­ внутрь", в котором мы рассматриваем систему наподобие луковицы, с которой последовательно снимаются слои. Сверка документов Чтобы быть полезным, описание любого блока должно, как мини­ мум, включать в себя описание объектов, которые блок создает в ре­ зультате своей работы ("выхода"), и объектов, которые блок потреб­ ляет или преобразует ("вход"). В IDEFO также мрделируются управление и механизмы испол­ нения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм ис­ полнения — объекты, которые непосредственно выполняют преобра­ зование входа в выход, но не потребляются при этом сами по себе. Для отображения категорий информации, присутствующих на диаграммах IDEFO, существует аббревиатура ICOM, отображающая четыре возможных типа стрелок: I (Input) — вход — нечто, что потребляется в ходе выполнения процесса; С (Control) — управление — ограничения и инструкции, влияю­ щие на ход выполнения процесса; О (Output) — выход — нечто, являющееся результатом выполне­ ния процесса; М (Mechanism) — исполняющий механизм — нечто, что исполь­ зуется для выполнения процесса, но не потребляется само по себе. пов соединяется со своей стороной функционального блока. Стрелка входа / j Стрелка ^ управления \ Функциональный блок i , "ъ Стрелка ^ механизма испол нения Стрелка выхода Л. функционального блока Для названия стрелок, как правило, употребляются имена сущест­ вительные. Стрелки могут представлять собой людей, места, вещи, идеи или собьггия. Как и в случае с функциональными блоками, при­ своение имен всем стрелкам на диаграмме является только необходи­ мым условием для понимания читателем сути изображенного. От­ дельное описание каждой стрелки в текстовом виде может оказаться критическим фактором для построения точной и полезной модели. Стрелки входа. Вход представляет собой сырье, или информа­ цию, потребляемую или преобразуемую функциональным блоком для производства выхода. Стрелки входа всегда направлены в левую сто- рону прямоугольника, обозначающего в IDEFO функциональный блок. Наличие входных стрелок на диаграмме не является обязатель­ ным, так как возможно, что некоторые блоки ничего не преобразуют и не изменяют. Примером блока, не имеющего входа, может служить "принятие решения руководством", где для принятия решения анали­ зируется несколько факторов, но ни один из них непосредственно не преобразуется и не потребляется в результате принятия какого-либо решения. Стрелки управления. Стрелки управления отвечают за регули­ рование того, как и когда выполняется функциональный блок, и, если он выполняется, какой выход получается в результате его выполне­ ния. Так как управление контролирует поведение функционального блока для обеспечения создания желаемого выхода, каэюдый функ­ циональный блок долэ/сен иметь, как минимум, одну стрелку управ­ ления. Стрелки управления всегда входят в функциональный блок сверху. Управление часто существует в виде правил, инструкций, зако­ нов, политики, набора необходимых процедур или стандартов. Влияя на работу блока, оно непосредственно не потребляется и не трансфор­ мируется в результате. Может оказаться, что целью функционального блока является как раз изменение того или иного правила, инструк­ ции, стандарта и т.п. В этом случае стрелка, содержащая соответст­ вующую информацию, должна рассматриваться не как управление, а как вход функционального блока. Управление можно рассматривать как специфический вид входа. В случаях, когда неясно, относить ли стрелку к входу или к управле­ нию, предпочтительно относить ее к управлению до момента, пока не­ ясность не будет разрешена. Стрелки выхода. Выход — это продукция или информация, по­ лучаемая в результате работы функционального блока. Каэюдый блок долэюен иметь, как минимум, один выход. Действие, которое не произ­ водит никакого четко определяемого выхода, не должно моделиро­ ваться вообще (по меньшей мере, должно рассматриваться в качестве одного из первых кандидатов на исключение из модели). При моделировании непроизводственных предметных областей выходами, как правило, являются данные, в каком-либо виде обраба­ тываемые функциональным блоком. В этом случае важно, чтобы на­ звания стрелок входа и выхода были достаточно различимы по своему смыслу. Например, блок "Прием пациентов" может иметь стрелку "Данные о пациенте" как на входе, так и на выходе. В такой ситуации входящую стрелку можно назвать "Предварительные данные о паци­ енте", а исходящую — "Подтвержденные данные о пациенте". Стрелки механизма исполнения. Механизмы являются ресур­ сом, который непосредственно исполняет моделируемое действие. С помощью механизмов исполнения могут моделироваться: ключевой персонал, техника и (или) оборудование. Стрелки механизма испол­ нения могут отсутствовать в случае, если оказывается, что они не являются необходимыми для достижения поставленной цели моде­ лирования. Комбинированные стрелки. ВIDEFO существует пять основных видов комбинированных стрелок: выход — вход, выход — управле­ ние, выход — механизм исполнения, выход — обратная связь на управление и выход — обратная связь на вход. Стрелка выход — вход применяется, когда один из блоков должен полностью завершить работу перед началом работы другого блока. заказа. РР-. принять заказ Позиции заказа Выписать счет Стрелка выход — управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. управляют поведением брокеров на бирже. Выбрать виды ценных бумаг для инвестирования Принципы формирования инвестиционного портфеля ' ' Приступить к покупке ценных бумаг Стрелки выход — механизм исполнения встречаютс реже и отра­ жают ситуацию, когда выход одного функциональног блока приме­ зажим, устройство, используемое для закрепления детали во время ее сборки, должно быть собрано для того, чтобы выполнить сборку детали. Собрать зажим Собрать деталь I Зажим Обратные связи на вход и на управление применяются в случаях, когда зависимые блоки формируют обратные связи для управляющих щих биржевых курсах применяется для корректировки стратегии иг­ ры на бирже. Г Информация о текущих курсах Выбрать виды ценных бумаг для инвестирования Принципы формирования инвестиционного портфеля Приступить к покупке ценных бумаг Ор Стрелка выход — обратная связь на вход обычно применяется для жить примером применения стрелки такого типа. Кроме того, связи выход — обратная связь на вход могут применяться в случае, если бракованная продукция может заново использоваться в качестве сы­ рья, как это происходит, например, при производстве оконного стек- Деталь, нуждающаяся в повторной покраске Очистить и покрасить деталь Окрашенная деталь Провести контроль качества работ J Готовая продукция ^ ла, когда разбитое в процессе производства стекло перемалывается и переплавляется заново вместе с обыкновенным сырьем. Разбиение и соединение стрелок. Выход функционального блока может использоваться в нескольких других блоках. Фактически чуть ли не главная ценность IDEFO заключается в том, что эта методология помогает выявить взаимозависимости между блоками системы. Соот­ ветственно IDEFO предусматривает как разбиение, так и соединение стрелок на диаграмме. Разбитые на несколько частей стрелки могут иметь наименования, отличающиеся от наименования исходной стрелки. Исходная и разбитые (или объединенные) стрелки в совокуп­ ности называются связанными. Такая техника обычно применяется для того, чтобы отразить использование в процессе только части Аналогичный подход применяется и к объединяемым стрелкам. Изъять документацию для проверки Учредительные и финансовые документы Финансовые документь Провести проверку правильности начисления налогов ' г Проверить правильность постановки на учет Понятие связанные стрелки используется для управления уров­ нем детализации диаграмм. Если одна из стрелок диаграммы отсутст­ вует на родительской диаграмме (например, ввиду своей несущест- венности для родительского уровня) и не связана с другими стрелками той же диаграммы, точка вход этой стрелки на диаграмму или выхода ративная информационная система" — важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не использует­ ся в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несуще­ ственных для их уровня стрелок. Производственный отдел i i Модуль производственного отдела Корпоративная информационная система Ор. Отдел продаж - i Модуль отдела продаж Кроме того, туннели применяются для отражения ситуации, когда стрелка, присутствующая на родительской диаграмме, отсутствует в Производственный отдел Модуль производственного отдела Корпорат! система Авная дионная Отдел продаж , i Модуль отдела продаж нель у стрелки "модул производственного отдела" обозначает, что на диаграмме декомпозиции производственного отдела отсутствует стрелка механизма управления с соответствующим наименованием. в этом подразделе мы рассмотрим методику построения моделей IDEFO более подробно. щейся на ее полях служебной информацией. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов AUTHOR: Семенов Илья Олегович PROJECT: Отдел учета и отчетности RECOMMENDED PVPMQAT'QN AQ- Данные о Начисления Отсрочки плательщиках Обработка данных Поступления U ^ Методо­ логия ' Ведение лицевых карточек налогоплательщиков — юридических лиц Запросы налого­ плательщиков Карточки лицевых счетов Прочие ^ документы Подготовка отчетности, анализ и прогнозирование А Запросы на формирован Отчет-^ ность ^е MODE: АО TITLE: Отдел учета и отчетности NUMBER: (заголовка и "подвала"). Элементы заголовка используются дл отсле­ живания процесса создани модели. Элементы "подвала" отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели. Элементы заголовка диаграммы IDEFO Поле USED AT Author, date, project Назначение Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вруч­ ную) Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась | При ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление Status Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализа­ ции формального процесса публикации с шагами пере- смотра и утверждения Working Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы Draft Диаграмма достигла некоторого приемлемого для чита- телей уровня и готова для представления на утверждение Recommended Диаграмма одобрена и зггверждена. Какие-либо измене­ ния не предвидятся Publication Диаграмма готова для окончательной печати и пуб­ ликации Reader ФИО читателя Date Дата знакомства читателя с диафаммой Context Набросок расположения функциональных блоков на ро­ дительской диаграмме, на котором подсвечен деком­ позируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР Элементы "подвала" диаграмм IDEFO Node Title Number (еще называют С- Number) Назначение Номер диаграммы, совпадающий с номером родительского функционального блока. Имя родительского функционального блока. Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия данной диаграммы будет иметь новое значение в этом поле. Как правило, C-Number со­ стоит из инициалов автора (которые предполагаются уникаль­ ными среди всех аналитиков проекта) и последовательного кации эти номера могут быть заменены стандартными номера­ ми страниц. Если диаграмма замещает другую диаграмму, но­ мер заменяемой диаграммы может быгь заключен в скобки — нений всех диаграмм модели. | Подобно циклу автор-редактор, применяющемуся в книгоизда­ тельском деле, диаграммы IDEFO пересматриваются и изменяются для обеспечения точности отражения предметной области и улучше­ ния своего качества. Для каждого рецензента автором, как правило, подготавливается свой набор диаграмм. Предложения по изменениям и исправлениям возвращаются рецензентами автору для внесения их в модель. При возникновении разногласий между автором и рецензентом спорная диаграмма обычно рассылается всем рецензентам для достижения группового консенсуса. Формально механизм рецензирования и модификации диаграмм поддерживается полями Status и нумерацией диаграмм, контроль ис­ Ни одна модель не должна строиться без ясного осознания объек­ та и целей моделирования. Выбранное определение цели моделирова­ ния должно отвечать на следующие вопросы: • Почему моделируется данный процесс? • Что выявит данная модель? • Как ознакомившиеся с этой моделью смогут ее применить? Следующее предложение может служить примером формулиро­ вания цели моделирования. Выявить задачи каждого работника ком­ пании и понять в целом взаимосвязь между отдельно взятыми задача­ ми для разработки руководства по обучению новых сотрудников. Модели строятся для того, чтобы ответить на набор поставленных вопросов. Такие вопросы формулируются на ранних стадиях модели­ рования и впоследствии служат основой для четкого и краткого опре­ деления цели моделирования. Примерами таких вопросов могут быть: • Каковы задачи менеджера? • Каковы задачи клерка? • Кто контролирует работу? • Какая технология нужна для выполнения каждого шага? и т.п. С методической точки зрения при моделировании полезно ис­ пользовать мнение экспертов, имеющих разные взгляды на предмет­ ную область, однако каждая отдельно взятая модель должна разраба­ тываться исходя из единственной заранее определенной точки зрения. Часто другие точки зрения вкратце документируются в прикреплен­ ных диаграммах FEO (см. ниже) исключительно для наглядности из­ ложения. Точку зрения нужно подбирать достаточно аккуратно, основой для выбора должна служить поставленная цель моделирования. На­ именованием точки зрения может быть наименование должности, подразделения или роли (например, руководитель отдела или менед­ жер по продажам). Как и в случае с определением цели моделирова­ ния, четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного из­ менения ее структуры. Может оказаться необходимым построение моделей с разных точек зрения для детального отражения всех осо­ бенностей вьщеленных в системе функциональных блоков. Одним из положительных результатов построения функциональ­ ных моделей оказывается прояснение границ моделирования системы в целом и ее основных компонентов. Хотя и предполагается, что в процессе работы над моделью будет происходить некоторое измене­ ние границ моделирования, их вербальное (словесное) описание должно поддерживаться с самого начала для обеспечения координа­ ции работы участвующих в проекте аналитиков. Как и при определе­ нии цели моделирования, отсутствие границ затрудняет оценку степе­ ни завершенности модели, поскольку границы моделирования имеют тенденцию к расширению с ростом размеров модели. Границы моделирования имеют два компонента: ширину охвата и глубину детализации. Ширина охвата обозначает внешние границы моделируемой системы. Глубина детализации определяет степень подробности, с которой нужно проводить декомпозицию функцио­ нальных блоков. Чтобы облегчить правильное определение границ моделирования при разработке моделей IDEFO, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEFO (диа­ граммы "самого верхнего" уровня). Иногда даже прибегают к по­ строению дополнительной диаграммы для отображения уровня, более высокого, чем контекстный, для данной модели, что позволяет обо­ значить систему, внутри которой располагается объект для моделиро­ вания. Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является своего рода "точкой отсче­ та" для остальных диаграмм модели и вносимые в нее изменения кас­ кадом отражаются на все лежащие ниже уровни. Когда границы моделирования понятны, становятся ясными и причины, по которым некоторые объекты системы не вошли в модель. контекстного блока Рекомендуемой последовательностью действий при построении модели "с нуля" являются: формулирование цели моделирования, вы­ бор точки зрения, определение границ моделирования. Наименование контекстного блока — функционального блока самого высокого уровня — обобщает определение границ моделирования. Правила подбора имени для контекстного блока в целом не отли­ чаются от общих правил наименования функциональных блоков, поэтому для них обычно подбирают обобщающие названия, типа "Управление отделом по работе с клиентами", "Обработка заказов" и т.п. диаграмме Стрелки диаграмм IDEFO обычно проще проектировать в следую­ щем порядке: выход, вход, механизм исполнения, управление. Каж­ дый функциональный блок обозначает отдельную функцию, и эта функция часто имеет ясно и кратко описываемые результаты работы. Наличие неясностей при анализе выходов того или иного функцио­ нального блока — возможный сигнал необходимости проведения ре­ инжиниринга рассматриваемого бизнес-процесса. Определение выходов. После идентификации возможных выхо­ дов полезно провести анализ модели на предмет покрытия ею всех возмоэюных сценариев поведения процесса. Это означает, что если су­ ществует вероятность возникновения той или иной ситуации в ходе процесса, модель отражает возможность возникновения такой ситуа­ ции. Многие начинающие аналитики забывают отразить негативные результаты работы функциональных блоков. Например, блок "Про­ вести экзамен по вождению" определенно произведет поток водите­ лей, только что получивших права, но вполне правомерно ожидать и потока лиц, не сдавших экзамен. Негативные результаты часто ис­ пользуются в качестве обратных связей, анализ на их наличие должен проводиться для каждого блока. Важным также является необходи­ мость включения в модель спорных стрелок, принятие решения о на­ личии которых в модели вполне можно переложить на плечи рецензи­ рующих модель экспертов. Определение входов. Входы можно рассматривать как особым образом преобразуемые функциональными блоками для производст­ ва выхода сырье или информацию. В производственных отраслях оп­ ределить, как входное сырье преобразуется в готовую продукцию, обычно довольно просто. Однако при моделировании информацион­ ных потоков входной поток данных может представляться не потреб­ ляемым и не обрабатываемым вообще. Случаи, когда входящие и ис­ ходящие стрелки называются в точности одинаково, крайне редки и в основном указывают на бесполезность данного блока для системы в целом или на некорректный выбор имени для исходящей стрелки. Ре­ шением может служить применение более подробного описания для входящих и исходящих потоков данных. Например, вход может иметь название "Предварительный диагноз пациента", а выход — "Уточнен­ ный диагноз пациента". Определение механизмов исполнения. После создания входов и выходов можно приступить к рассмотрению механизмов исполнения, или ресурсов, относящихся к функциональному блоку. В понятие ме­ ханизма исполнения входят персонал, оборудование, информацион­ ные системы и т.п. Например, функциональный блок "Собрать де­ таль" может потребовать использования какого-либо оборудования, например гаечного ключа. При приеме экзаменов на водительские права механизмом исполнения является инспектор ГИБДД. Как пра­ вило, определить механизмы исполнения для функциональных бло­ ков довольно просто. Определение управления. Должно быть определено управление, контролирующее ход работы функционального блока. Все функцио­ нальные блоки в IDEFO должны иметь хотя бы одно управление. В случаях, когда не ясно, относить ли стрелку к входу или к управле­ нию, следует ее рисовать как управление. Важно помнить, что управ­ ление можно рассматривать как особую форму входа функционально­ го блока. Когда контекстная диаграмма представляется завершенной, по­ пробуйте задать следующие вопросы: • Обобщает ли диаграмма моделируемый бизнес-процесс? • Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования? • Подходит ли выбранный уровень детализации стрелок для контек­ стного блока? (Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа.) Все функциональные блоки IDEFO нумеруются. В номерах до­ пускается использование префиксов произвольной длины, но в по­ давляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер АО. Префикс повторяется для каждого блока модели. Номера исполь­ зуются для отражения уровня декомпозиции, на котором находится ляется одна цифра. Связь между диаграммой и ее родительским функциональным блоком Функциональный блок декомпозируется, если необходимо де­ тально описать его работу. При декомпозиции блока полезно рассмот­ реть его жизненный цикл, это поможет определить функциональные блоки получающейся "детской" диаграммы. Например, жизненный цикл блока "Поджарить бифштекс" может выглядеть как следующая последовательность: "Подготовить продукты", "Отбить мясо", "Разо­ греть масло" и т.д. При моделировании IDEFO важно иметь в виду, что граница дет­ ской диаграммы есть граница родительского функционального блока. Это означает, что вся работа выполняется блоками самого нижнего уровня. В отличие от иерархии, применяемой в сфуктурном програм­ мировании, блоки верхнего уровня не являются субъектами управле­ ния для блоков нижнего уровня. Это означает, что в IDEFO дети — это те же объекты, что и их родители, только показанные с большей дета­ лизацией. Действия генерального директора компании на диаграммах IDEFO могут отражаться рядом с действиями простых рабочих. На концах граничных стрелок (начинающихся или заканчиваю­ щихся за пределами диаграммы) детских диаграмм помещаются коды ICOM, чтобы показать, где находится соответствующая стрелка на ности модели и могут быть полезны, когда порядок расположения стрелок на детской диаграмме отличается от порядка их расположе­ ния на родительской диаграмме. Код ICOM состоит из латинской бук­ вы I, С, О или М и числа, показывающего расположение стрелки на ро­ дительской диаграмме в порядке сверху вниз или слева направо. а^ • ("в ширину" и " глубину") Модели могут проектироваться с использованием подхода "в ши­ рину", когда каждая диаграмма максимально детализируется перед своей декомпозицией, и с подходом "в глубину", когда сначала опре­ деляется иерархия блоков, а затем создаются соединяющие их стрел­ ки. Естественно, возможно применение комбинации этих подходов, причем иерархия блоков может иногда немного измениться после то­ го, как нарисованы стрелки. Это происходит из-за того, что создание стрелок может изменить понимание внутренней архитектуры модели­ руемого объекта. Сформулированная цель моделирования содержит вопросы, на которые должна отвечать модель. Когда становится возможным полу­ чение ответов на них с помощью модели, модель считается удовлетво­ ряющей поставленным требованиям и рассматривается как завершен­ ная. При построении декомпозиции первого уровня нужно следить за тем, чтобы все блоки на диаграмме лежали внутри определенных ра­ нее границ моделирования. Перед декомпозированием блока нужно удостовериться, не приведет ли это к превышению установленной ра­ нее глубины детализации для данной модели. Еще одно правило со­ стоит в том, что моделирование IDEFO должно продолжаться до тех пор, пока стрелки предшествования (вход и выход) преобладают на диаграммах. При необходимости дальнейшей детализации отдельных процес­ В дополнение к контекстным диаграммам и диаграммам декомпо­ зиции при разработке и представлении моделей могут применяться другие виды IDEFO-диаграмм. Дерево модели. Это обзорная диаграмма, показывающая структу­ Обычно вершина дерева соответствует контекстному блоку, под вер­ шиной выстраивается вся иерархия блоков модели. Однако не запре­ щается назначать вершиной произвольный блок, помещая под ним все его детские блоки. Из-за высокой итеративности функционального моделирования можно ожидать, чт дерев модели будет неоднократ­ но изменяться существенным образом до тех пор, пока не будет по­ лучена его стабильная версия. Обзор модели с использованием дере­ ва помогает сконцентрироваться на функциональной декомпозиции модели. Сверка документов Обработка данных ^"Z^^^^^ Обработка невыясненных платежей г Формирование данных для лицевых карточек з Презентационные диаграммы. Презентационные диаграммы (For Exposition Only diagrams — FEO diagrams) часто включают в мо­ дели, чтобы проиллюстрировать другие точки зрения или детали, вы­ ходящие за рамки традиционного синтаксиса IDEFO. Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEFO в целях выделения важных с точки зрения аналитика частей модели. Ес­ тественно, если диаграмма FEO включена в модель исключительно для отображения другой точки зрения на систему, она скорее всего будет выглядеть как обыкновенная диаграмма IDEFO, удовлетворяя всем ограничениям IDEFO. Один из способов использования FEO-диаграмм состоит в отделе­ нии функционального блока от его окружения посредством создания диаграммы с единственным блоком и всеми относящимися к нему оказаться полезным в ситуациях, когда необходимо быстро получить информацию об интерфейсе (стрелках) функционального блока, а со­ ответствующая диаграмма декомпозиции содержит слишком много объектов. Кроме того, встречаются следующие виды презентационных диа­ грамм: • копия диаграммы IDEFO, которая содержит все функциональные блоки, и стрелки, относящиеся только к одному из функциональ­ ных блоков, — это позволяет отразить взаимодействие между этим блоком и другими объектами диаграммы; AUTHOR Семенов Илья Олегович PROJECT Отдел учета и отчетности И/ПРЮМП RECOMMENDED PUBLICATION RFARFR HATF Начисления Отсрочки Поступления Данные о налого­ плательщиках Методо­ логия f Ведение лицевых карточек налогоплательщиков — юридических лиц i Запросы налого­ плательщиков Карточки лицевых счетов Прочие ^ документы MODE: АО TITLE: Ведение лицевых карточек налогоплательщиков — ЮЛ NUMBER: и его стрелок • копия диаграммы IDEFO, которая содержит все функциональные блоки, и стрелки, непосредственно относящиеся только к входу и (или) к выходу родительского блока; • различные точки зрения, как правило, на глубину одного уровня декомпозиции. в функциональных блоках Как правило, при работе с пластиковой картой клиент не произво­ дит всех доступных ему при этом действий, выполняя офаниченный набор операций. Например, при оплате покупки не производится сня- тие наличных, а при проверке баланса состояни счет вообщ не изменяется (это верно, конечно, только в случае, если карта обслужи­ вается приличным банком). Мы можем декомпозировать функцио­ нальный блок "Обработка операций с пластиковыми картами", создав дополнительные блоки для оплаты покупок, снятия наличных, про­ верки баланса и т.п. Вместо этого можно создать отдельные модели дальнейшем предполагается заняться оцениванием соответствующих операций по тем или иным параметрам. Более простой альтернативой предложенным выше двум подхо­ дам может служить так называемая таблица вызова (activation table), описывающая различные комбинации входов, выходов, управлений и механизмов исполнения для каждого способа вызова функциональ­ ного блока на исполнение. Вызов — это уникальная конфигурация значений входа, управления и требований к механизмам исполнения лах блока и перечисляются значения различных стрелок. Комбинация значений стрелок должна быть уникальной для каждого вызова, из че­ го следует, что для каждого вызова любые две одинаковые стрелки не могут иметь одинаковых значений. Таблица вызовов для блока ^Подсчитать наличные'' Вызов Значительная сумма наличных денег Мелкая сумма наличных денег Стрелка Наличные деньги Счетчик банкнот Наличные деньги Счетчик банкнот Значение стрелки формацию о стрелках управления данного функционального блока. Например, мы можем предположить, что политика банка при подсче­ те сумм наличных заключается в использовании счетчиков банкнот для отображения блоков IDEFO Для иллюстрирования вызовов листовых функциональных блоков IDEFO (т.е. блоков, не имеющих диаграмм декомпозиции) может быть предполагается аналитиками именно таким способом, моделями вызов функционального блока. Соответствующие таблицы вызовов Ит^к, методология функционального моделирования IDEFO — это технология описания системы в целом как множества взаимозави­ симых действий, или функций. IDEFO имеет функциональную направ­ ленность. IDEFO — функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Одной из основных идей моделей IDEFO является построение дв>^ видов моделей: "как есть" и "как должно быть". Это нужно при проведении реинжинирин­ га бизнес-процессов организации. Кроме того, IDEFO обеспечивает удобный язык обмена информацией о моделируемой системе. ГЛАВА СТРУКТУРНЫЙ АНАЛИЗ ПОТОКОВ ДАННЫХ (DFD — DATA FLOW DIAGRAMS) потоков данных Так же, как и диафаммы IDEFO, диаграммы потоков данных моде­ лируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных также могут содержать два новых типа объектов: объекты, собирающие и хранящие инфор­ мацию — хранилища данных и внешние сущности — объекты, кото­ рые моделируют взаимодействие с теми частями системы (или дру­ гими системами), которые выходят за границы моделирования. На В отличие от стрелок в IDEFO, которые иллюстрируют отноше­ ния, стрелки в DFD показывают, как объекты (включая и данные) ре­ ально перемещаются от одного действия к другому. Это представле­ ние потока вкупе с хранилищами данных и внешними сущностями обеспечивает отражение в DFD-моделях таких физических характери­ стик системы, как двиэюение объектов (потоки дт^ых), хранение объ­ ектов (хранилища данных), источники и потребители объектов (внешние сущности). Построение DFD-диаграмм в основном ассоциируется с разработ­ кой программного обеспечения, поскольку нотация DFD изначально была разработана для этих целей. В частности, графическое изображе­ ние объектов на DFD-диаграммах этой главы соответствует принято­ му Крисом Гейном (Chris Gane) и Тришем Сарсоном (Trish Sarson), ав­ торами DFD-метода, известного как метод Гейна — Сарсона. Другой распространенной нотацией DFD является так называемый метод Йордана — Де Марко (Yourdon — DeMarco). Данные заказа Клиенты Заказы Информация о доставке Заказы Обработать заказы Название клиента, адрес клиента Данные счетов Счета Данные счетов Склад Продукция _£ Клиенты Название клиента, адрес клиента Доставить продукцию Название клиента, адрес клиента Продукция Проконтроли­ ровать оплату Счета / Платежные документы _ ] f Клиенты диаграмм потоков данных в отличие от IDEFO, рассматривающего систему как множество взаимопересекающихся действий, в названиях объектов DFD-диа- фамм преобладают имена существительные. Контекстная DFD-диа- грамма часто состоит из одного функционального блока и нескольких внешних сущностей. Функциональный блок на этой диаграмме обыч­ Добавление на диаграмму внешних ссылок не изменяет фунда­ ментального требования, что модель должна строиться с единствен­ ной точки зрения и должна иметь четко определенные цель и границы, что уже обсуждалось ранее. Поставщики оборудования \ ' Поставщики материалов ' / • г Департамент по работе с пластиковыми картами i ^ к ^ i Департамент маркетинга и рекламы ' Департамент по работе с клиентами Функциональный блок DFD моделирует некоторую функцию, ко­ торая преобразует какое-либо сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они с ( V / Юбл Департамент по работе : пластиковыми картами Персонал Оборудование ) ^ ' ОАГ^%#Г строенной в нотации Гейна — Сарсона почти идентичны функциональ­ ным блокам IDEFO и действиям функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEFO. В не­ которых интерпретациях нота­ ции DFD Гейна — Сарсона механизмы исполнения IDEFO моделируются как ресурсы и изображаются в нижней части Внешние сущности обеспечивают необходимые входы для сис­ темы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функциони­ руя как поставщик) и принимать выходы (функционируя как по­ лучатель). Внешние сущности изображаются щаются у краев диаграммы. Одна внешняя сущность может быть размещена на одной и той же диаграмме в нескольких экземплярах. Этот прием полезно применять для сокраще­ ния количества линий, соединяющих объекты на диаграмме. Клиент внешней сущности Стрелки описывают передвижение (поток) объектов от одной час­ ти системы к другой. Поскольку все стороны обозначающего функ­ циональный блок DFD прямоугольника равнозначны (в отличие от IDEFO), стрелки могут начинаться и заканчиваться в любой части бло­ ка. В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, ленная стрелка обозначает взаимный обмен информацией между де­ партаментами маркетинга и рекламы и пластиковых карт. Op. о Департамент по работе с пластиковыми картами Департамент маркетинга и рекламы В то время как потоки данных представляют объекты в процессе их передвижения, хранилища данных моделируют их во всех осталь­ ных состояниях. При моделировании производственных систем хра­ нилищами данных служат места временного складирования, где хранится продукция на промежуточных стадиях обработки. В инфор­ мационных системах хранилища данных пред­ ставляют любой механизм, который поддержи­ вает хранение данных для их промежуточ­ обозначения хранилищ данных на DFD-диа- граммах. Заказы хранилища данных на DFD-диаграмме Стрелки на DFD-диаграммах могут быть разбиты (разветвлены) на части, и при этом каждый получившийся сегмент может быть пере­ именован таким образом, чтобы показать декомпозицию данных, пе­ Записать адрес клиента Адрес клиента Почтовый индекс Город Улица Проверить почтовый индекс Ор. з] Проверить город Проверить улицу Проверить почтовый индекс Проверить город Проверить улицу Корректный почтовый индекс Проверенное название города Проверенная улица Корректный адрес клиента Обработка заказа Стрелки могут и соединяться между собой (объединяться) для формирования так называемых комплексных объектов. Пример тако­ потоков данных Диаграммы DFD можно строить с использованием подхода, ана­ логичного структурному методу анализа и проектирования, приме­ няемому в IDEFO. Вначале строится модель физической реализации реальной системы, которая используется пользователями в настоящее время. Затем создается логическая модель текущего состояния систе­ мы для моделирования основных требований существующей систе­ мы. После этого создается новая логическая модель для отражения основных параметров предлагаемой разрабатываемой системы. Нако­ нец, создается новая физическая модель, реализующая логическую модель новой системы. В настоящее время при разработке информационных систем за­ воевывает все большую популярность альтернативный подход, из­ вестный как разделение событий, в котором для моделирования сис­ темы строится несколько моделей DFD. Вначале строится логическая модель, отображающая систему как набор действий и описывающая, что должна делать система. Затем строится модель окруэюения, описывающа систему как объект, отвечающий на события, порождаемые внешними сущностя­ ми. Такая модель обычно состоит из описания назначения системы, одной диаграммы контекстного уровня и списка событий. Контекст­ ная диаграмма содержит один функциональный блок, представляю­ щий систему в целом, и внешних сущностей (окружения), с которыми система взаимодействует. На заключительном этапе создается модель поведения, показы­ вающая, как система обрабатывает те или иные события. Эта модель начинается с единственной диаграммы с одним функциональным бло­ ком на каждый ответ системы на событие, описанное в модели окру­ жения. Хранилища данных в модели поведения используются для мо­ делирования данных, которые должны сохраняться в промежутках между обработкой событий. Потоки применяются для соединения элементов диаграмм между собой и для проверки согласованности моделей поведения и окружения. При подготовке такого рода моделей к различным презентациям обычно необходима их "чистка". При этом может применяться как создание упрощенных родительских диаграмм посредством объеди­ нения нескольких функциональных блоков в один, так и декомпози­ ция некоторых элементов для более ясного восприятия модели. В DFD каждый номер функционального блока может включать в себя префикс, номер родительской диаграммы и собственно номер рует функциональный блок на диаграмме. Номер родительской диа­ граммы и номер объекта в совокупности обеспечивают уникальную идентификацию каждого блока модели. Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней сущности вне зависимости от расположе­ ния объекта на диаграм- „ ^ .. ^ jr ^ Префикс Номер объекта ме. Каждый номер храни- •-^....,^^^^^ - префикс D (от английско- ^ го Data Store) и уникаль- Номер диаграммы Аналогично каждый номер каждо внешне сущности содержит префикс Е (от английского External entity) и уникальный номер сущ­ Итак, диаграммы потоков данных (DFD) обеспечивают удобный способ описания передаваемой информации как между частями моде­ лируемой системы, так и между системой и внешним миром. Это ка­ чество определяет область применения DFD — они используются для создания моделей информационного обмена организации, например модели документооборота. Кроме того, различные вариации DFD ши­ роко применяются при построении корпоративных информационных систем. ГЛАВА ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IDEF-МОДЕЛИРОВАНИЯ Platinum BPWin — руководство пользователя программного пакета компьютерной поддержки технологии моделированияIDEF в этом подразделе приведено описание работы с наиболее попу­ лярным в настоящее время пакетом IDEF-моделирования Platinum BPWin. С использованием BPWin получено большинство иллюстра­ ций этой книги. В приложении приведено краткое описание работы с другим пакетом, поддерживающим технологию IDEF-моделирова­ ния — DesignЯDEF. Platinum BPWin имеет в своем составе программу "Наставник", позволяющую быстро ознакомиться как с основами IDEF-моделиро- вания, так и с их реализацией в BPWin. Приведенное ниже описание работы с BPWin по сути является сокращенным вариантом учебного курса, предлагаемого пользователям программой "Наставник". На Обучающая программа построена на выполнении типичных для BPWin задач делового моделирования. Каждый раздел обучающей программы строится на информации, полученной при изучении пре- дьщущего раздела, поэтому рекомендуется изучать их в предлагаемой последовательности. Рассмотрим последовательно разделы, предла­ гаемые "Наставником". Этот подраздел предназначен для тех, кто плохо знаком с деловым моделированием. Он начинается с обзора, охватывающего базовые идеи делового моделирования и основную терминологию. Каждый подраздел этой темы также содержит описание типовых меню и диа­ логов, с которыми придется работать при выполнении различных за­ дач. Для более подробных пояснений по содержанию экранов доста­ точно просто щелкнуть на соответствующей области. 'ISf ln^(>««iv »M*~*A •«*• *«>i#'^l»*» t л iri; Kl^dH i'rr-jif»irtiii^.. После ознакомления с крат­ ким обзором можно приступить к выполнению заданий на типо­ вой модели, предоставляемой совместно с обучающей про- фаммой. Для этого на послед­ ней странице изучаемой темы всегда появляется Кнопка "Try Щелчок на ней позволяет пе­ рейти к пс'шаговому выполне­ нию практических упражнений. Типовые модели подготавлива­ ются и используются совместно с тренировочными упражне­ ниями. После нажатия кнопки "Try It" обучающая программа пред­ ставляет набор последователь­ ных подсказок (Que Cards) для облегчения выполнения задания, при этом в качестве наглядных примеров используется типовая модель В "Наставнике" имеется также возможность перейти непосредст­ венно к выполнению практических упражнений без просмотра теоре­ тического материала. Для этого достаточно нажать кнопку Try It в лю­ бом разделе главного меню "Наставника". Notice that а blank activity box has been created and the title bar shows the new model name and: • Right-click on the context activity. The shortcut menu ia di^layed. • Select Name Editor... The IDEFO Name Properties dialog box is displayed. The cursor is in the name entry field. • Type: PROCESS[Enter key] OSSER then press OK. ^•The (Enter key] places each word on a separate line. The coniexi activity is now named. Click Next Step > выполнения задания В "Наставнике" существует возможность проверки правильности выполнения каждой задачи — для этого достаточно нажать кноп­ ку "Check". Проверка покажет, как должна выглядеть модель в слу­ чае, если были бы выполнены все рекомендации обучающей програм­ мы. Чтобы возвратиться к кнопке "Try It", на подсказке достаточно закрыть окно просмотра результатов работы. Чтобы возвратиться к обучающей программе, достаточно щелкнуть по кнопке "Done" окна "Try It". бизнес-процессов? Сегодня в сложном и постоянно изменяющемся мире интересы деловых людей должны быть сосредоточены на процессе удовлетво­ рения потребностей клиентов. Работаете ли Вы в маленькой или боль­ шой организации, процесс производства, поставки товаров или услуг определяют качество и в конечном итоге успех Вашего бизнеса. Усовершенствование бизнес-процессов включает отображение и моделирование всех стадий деятельности компании для лучшего по­ нимания и усовершенствования проводимых операций. Можно моде­ лировать деятельность организации в целом или ее части, например процесс формирования требований к принятым в организации инфор­ мационным технологиям. Моделирование — один из наиболее эффективных методов для понимания и установления связи между деловыми правилами и биз­ нес-процессами компании. В процессе моделирования устраняются посторонние детали, а важная информация выдвигается на первый план для упрощения изучения системы. Графика (блоки и стрелки) используется для улучшения понима­ ния структуры модели, поэтому большинство людей думают о моде­ лях как об иллюстрированных представлениях. С использованием мо­ делирования бизнес-процессов Вы можете оценить систему так широко, чтобы все аспекты работы вашей организации могли быть проанализированы, поняты и, возможно, что наиболее важно, сообще­ ны другим. BPWin — мощный инструмент моделирования для анализа, доку­ ментирования и понимания комплексных бизнес-процессов. Моделирование полезно: • для устранения избыточных или ненужных блоков (функций); дл^ сокращения затрат; для совершенствовани работы компании; для повышения качества обсл>^ивания клиентов. С использованием BPWin строятся диаграммы бизнес-процессов, ясно показываюпще бизнес-процессы (блоки), результаты их работы и ресурсы, необходимые для их функционирования. BPWin-модель обеспечивает объединенную картину того, как организация добивает­ ся выполнения своих целей, от маленьких отделов до всей компании в Также можно использовать BPWin для моделирования потоков работ, потоков процессов и потоков данных. ;трслк« упрм/мния Стрелка •хода Я««ф функциональный блок I/.. ^IT'ieFr^ поддерживаемые BPWin -|¥tM(lli(^b^ ,Ыатв:| BPWin поддерживает три методологии моделирования: функциональное моделирование (IDEFO); • описание бизнес-процес­ • диаграммы потоков дан­ ных (DFD). Поддержкой трех мето­ дологий моделирования в одной программе BPWin объединяет три ключевых подхода к моделированию бизнес-процессов, что впол­ не удовлетворяет потребно­ сти как системных аналити­ ков, так и специалистов- технологов. При создании новой мо­ дели достаточно просто вы­ брать нужную методологию в диалоговом окне, появляю­ щемся каждый раз при созда­ нии новой модели BPWin ^ Bu«inm Process РЕРЩ OfC т^\ Функциональное моделирование является технологией анализа системы в целом как набора связанных между собой действий или функций. Действия системы анализируются независимо от объек­ та (ов), который обеспечивает их исполнение. Моделировать деловой процесс можно исходя из различных перспектив и временных рамок. Например, Вы можете смоделировать процесс заказа услуг клиентом так, как Вы видите его в идеале, а не так, как это происходит в настоя­ щее время. Карточки лицевых счетов Данные о налогоплательщиках Методология Формирование стандартных отчетов Формирование стандартных форм отчетности ПНИ Формирование нестандартных отчетов Запросы на формирование сведений Отчетность Формирование сведений по нестандартным запросам С функциональной точки зрения Вы можете также абстрагиро­ ваться от проблем физической реализации модели. Диаграммы потоков данных (DFD) моделируют системы как взаимосвязанный набор действий, которые обрабатывают данные в "хранилище" как внутри, так и вне границ моделируемой системы. Диаграммы потоков данных обычно применяются при моделирова­ нии информационных систем. Стрелки в DFD показывают, как объекты (данные) фактически взаимодействуют между собой. Это представление, объединяющее хранимые в системе данные и внешние для системы объекты, дает DFD-моделям большую гибкость для отображения физических харак­ теристик системы, таких, как проблемы обмена данными, разработка схем их хранения и обработки. значенная для обеспечения структурированного подхода к описанию бизнес-процесса как упорядоченной последовательности событий ON К) Данные заказа Клиенты Заказы Информация о доставке Заказы Обработать заказы Название клиента, адрес клиента Данные счетов Счета Данные счетов Склад Продукция г Клиенты Название клиента, адрес клиента Доставить продукцию Название клиента, адрес клиента Продукция Проконтроли­ ровать оплату Счета / Платежные документы _J ' f Клиенты & л ' ^ Проверить баланс на счете Проверить статус клиента ot; Проверить данные чека Подготовить сумму наличными О Н Напечатать и выдать чек ON одновременно с описанием любых участвующи в бизнес-процессе объектов и относящихся к ним правил. Создание диаграмм потоков работ — техника, хорошо подходя­ щая для сбора данных о системе и применяющаяся как часть струк­ турного подхода к анализу и проектированию системы. В отличие от строгого использования синтаксиса и семантики во избежание полу­ чения неполного или противоречивого описания системы. • для улучшения понимания результатов моделирования бизнес- процессов; • для определения момента окончания моделирования; • для сбора информации о схеме работы моделируемой компании. нальное моделирование системы по методологии IDEFO и получило заслуженное признание как довольно удобный способ анализа потен­ чивают дискретность моделирования процесса, что может использо­ ваться для контроля за ходом выполнения работ. IDEFO лучше всего применять как средство анализа и логического моделирования систем, что, как правило, выполняется на ранних ста­ диях работы над проектом. Данные анализа, полученные с использо­ ванием моделирования IDEFO, обычно используются на стадии разра­ ANALISYS REQ's DESIGN IDEFO \ ЬнннвнЫ N—i^ / DFD ^ / \ •N / Jan Feb Mar Apr May Jun Jul Aug Sep Рабочее место BPWin выполнен в виде рабочег стола, состояще­ го из нескольких окон. На рабочем столе размещены: меню; стандартная панель инструментов; панель инструментов ModelMart; дерево модели; область для рисования; панель инструментов BPWin; статусная строка. Панель Меню BPWin. Панель Меню BPWin соответствует стан­ дартам Windows и обеспечивает доступ ко всем функциям BPWin. Не­ которые из них: Печать. Чтобы открыть окно печати, на панели Меню выберите File, затем Print. Масштаб. На панели Меню выберите View, затем измените мас­ штаб изображения для активной диаграммы или для всех диаграмм в модели на тот, который Вам нужен. Стандартная панель инструментов. Стандартная панель инст­ мым задачам. Как и любая другая панель инструментов BPWin, стандартная па­ нель может быть расположена в любой стороне экрана или находиться в любом месте в области диаграммы. Вы можете также показывать или скрывать ее, используя функцию View на панели Меню. рый используется для просмотра структуры модели и изменения лю­ бых объектов диаграмм в любой открытой модели BPWin. Одновре- шишшшявшшиняишии am$ Начисления Отсрочки I, /:^нные о налогоплательщиках Поступления менно работая с несколькими моделями, можно рассматривать все диаграммы или только активные при свернутой и развернутой струк­ туре иерархического дерева. Для любой используемой методологии перечень исследуемых моделей дает полное представление о всей мо­ дели. С использованием дерева можно также выполнять задачи моде­ лирования. Вы можете показывать и скрывать дерево модели, щелкая кноп­ кой Model Explorer. Когда дерево модели активно, оно находится в раздвигающемся окне слева, а активная диаграмма — в правом. • для просмотра разных моделей, построенных с использованием различных методологий моделирования; • для переключения режимов просмотра диаграмм или действий; • для немедленного перехода к просмотру или работе с соответст­ вующей диаграммой в рабочем пространстве BPWin посредством щелчка на названии диаграммы или действия; • для просмотра действий и объектов диаграммы согласно уровням декомпозиции; • для редактирования имени модели, диаграммы или действия по­ средством двойного нажатия на соответствующем названии; • для просмотра соответствующих FEO-диаграмм, Node Tree или родственных диаграмм посредством щелчка на названии объекта диаграммы в иерархическом дереве. Область для рисовани — это больша площадь справа от главно­ го окна BPWin, в котором расположено дерево модели. Она состоит из трех областей: • заголовок; • область для рисования; • название. Когда дерево моделей скрыто, рисунок занимает полную область окна. Вы можете создавать диаграммы BPWin, редактировать их, управлять ими в области для рисования. По Вашему желанию диа- фамма может быть масштабирована при помощи инструментов на­ стройки масштаба. Панель инструментов BPWin содержит инструменты для рисова­ ния объектов в диаграмме BPWin. Эти инструменты могут быть раз­ мещены в любой стороне экрана или находиться где-то в области диа­ граммы. Вы можете показывать или скрывать панель инструментов, используя функцию View на панели Меню. В BPWin существуют три разные панели инструментов — по числу поддерживаемых програм­ шшвшшшшш [Тп|-^ тЮ!» HHpH>cii в А ш|| Ik'ol^ т|-о|о п • с А ^ • : Нужная панель инструментов подбирается программой автомати­ чески при выборе одной из предлагаемых при первоначальном созда­ нии модели методологий. При возникновении проблем в процессе работы с BPWin исполь­ зование Help — самый быстрый способ их решения. Чтобы присту­ пить к работе с BPWin Online Help, выберите раздел Help на панели Bmm^^iP^B^, \.йт^^^}- the Name tab in the Activity Property Sheet • Double-dick the diagram activity. • Double-click the activity tree object in the fyJft«teJ.Exp.iOJSr. name a new activity or change the name of an existing activity: • To use an existing activity name from the dictionary, select a name from the Unused Activi^ Names list. • To assign a new name. type a name in the text box. • To change the cunent name, type the change in the text box. Hint Tomodify alloccunences ofthe PmJm MSI иМмймМ. Меню, затем выберите один из предложенных вариантов и продолжи­ те поиск интересующей Вас темы. реть контекстно-зависимую помощь для текущего диалогового окна или варианта меню. Заметьте, что кнопка "Помощь" имеется также в шинстве диалоговых окон. Контекстная диаграмма — это модель, которая представляет сис­ тему как набор действий, в которые каждое действие преобразует не­ который объект или набор объектов. Модель представляется как на­ бор иерархических действий. Высшее действие иерархии называется действием контекста. Это самый высокий уровень, который непо­ средственно описывает систему. Уровни ниже называются порож­ денными декомпозициями и представляют подпроцессы родительско­ го действия. При создании модели сначала необходимо изобразить самый вы­ сокий уровень, действие контекста. Наименование действия описыва- ет систему непосредственно и, как правило, состоит из одного актив­ ного глагола в сочетании с обобщающим существительным, которое разъясняет цель деятельности с точки зрения самого общего взгляда на систему. Каждый блок может иметь различные типы связанных с ним стре­ лок. Стрелки обозначают людей, места, вещи, понятия или события. Стрелки связывают границы диаграммы с блоками, а также действия (блоки) на диаграмме между собой. В диаграммах IDEFO имеются че­ тыре основных типа стрелок. Вход блока представляет материал или информацию, которая должна быть использована или преобразована блоком, чтобы произ­ вести продукцию (выпуск). Стрелки входа всегда направляются в ле­ вую сторону блока. Стрелки входа необязательны, так как некоторые действия не могут преобразовать или изменять (заменять) что-либо. Каждый блок должен иметь, по крайней мере, одну стрелку кон­ троля (управления). Управление всегда входит в вершину блока. Управление представляется в виде правил, инструкций, политики, процедур или стандартов. Оно влияет на деятельность без фактиче­ ского преобразования чего-либо. Управление может также использо­ ваться для описания процедуры начала или окончания выполнения действия. Стрелки выхода (выпуска) — это материал или информация, про­ изведенная блоком. Каждый блок должен иметь, по крайней мере, од­ ну стрелку выхода (выпуска). Процессы, которые не производят про­ дукции (выпуска), лучше не моделировать вообще. Механизмы исполнения — это те ресурсы, которые обеспечивают выполнение действия. В качестве механизма исполнения могут бьггь рассмотрены персонал компании, машины или оборудование, кото­ рые обеспечивают выполнение деятельности. Стрелка механизма может отсутствовать, если определено, что это не важно для работы блока. Контекстная диаграмма изображает деятельность самого верхнего уровня и обозначает границу моделирования относительно цели, воз­ можностей, и точки зрения. Название контекстной диаграммы нахо­ дится в дереве модели непосредственно под общим описанием. Для создания контекстной диаграммы необходимо сначала соз­ дать новую модель, выбрав пункт "New" в меню "File". В появившем­ ся диалоговом окне необходимо набрать имя модели и выбрать ее тип. Этот диалог также отображается при запуске BPWin. Model Properties firoject ; ™ Time frame r- ' OK j ^ Отмена | ^ртёшгь ] ' Справка j После создания модели можно задать ее параметры. Список свойств модели — это диалог, в котором можно задать такие парамет­ ры, как полное наименование модели, ее словесное описание и состоя­ ние, в котором находится модель, например "в работе" или "для пуб­ Декомпозиционное разложение модели используется в моделиро­ вании бизнес-процессов, чтобы дать более подробное описание бло­ ков. Каждое из этих действий может в свою очередь быть декомпози­ ровано. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели. Обратите внима­ верхнем левом углу блока будет появляться символ "листа". После де­ композиции данного блока символ "листа" исчезнет. Как декомпозировать блоки с ис­ пользованием BPWin? Это может быть сделано двумя способами. В диаграмме - нужно выбрать действие, которое необ­ ходимо декомпозировать. Для этого вы­ берите необходимый инструмент в на­ боре инструментов BPWin или в дереве Р"^' ^'^^' Обозначение блока, модели, затем щелкните на действии, не имеющего декомпозиции которое нужно декомпозировать. Вы­ бранное меню содержит команду декомпозиции. В появившемся диа­ логовом окне необходимо задать тип и число необходимых подбло­ ков. При декомпозиции блока BPWin создает новую диаграмму, которая является диаграммой разложения "родительской" диаграм­ мы. Заметьте, что новые действия не связаны между собой и не поиме­ нованы — это Ваша следующая задача. Вы должны задать взаимо­ действие между блоками и "привязать" к новым блокам стрелки, которые автоматически унаследованы от родительской диаграммы. Имя блока и его другие свойства вводятся в закладке "Name" спи­ ска свойств блока. Для вывода свойств блока на экран достаточно два­ жды щелкнуть на блоке. Следующим шагом при создании диаграммы должно быть соеди­ нение всех использованных на диаграмме блоков с использованием стрелок, представляющих входы, результаты работы, средства управ­ ления и механизмы. Для этого достаточно соединить исходящую точ­ ку стрелки с точкой ее окончания. Окончанием стрелки может быть одна из сторон функциональных блоков и граница диаграммы. BPWin автоматически вьщеляет допустимые окончания для создаваемых стрелок. Для рисования стрелки необходимо выбрать инструмент "стрелка" из комплекта инструментов. Задание имени стрелки производится в закладке "Name" диалога свойств стрелок. Для вызова этого диалога достаточно дважды щелк­ нуть на нужной стрелке. Если стрелка заканчивается на границе диаграммы BPWin, она по­ мечается "туннелем" из квадратных скобок. Аналогично помечаются стрелки в родительской диаграмме, если в диаграмме декомпозиции удаляется перенесенная из нее стрелка. Квадратный туннель на начале стрелки указывает, что стрелка "не решена" в пределах иерархии мо­ дели (не имеется никакой другой стрелки с таким же именем в любой другой диаграмме модели). Для поддержания целостности модели не- обходимо "разрешать" стрелки, помеченные "туннелями" из квадрат­ ных скобок, одним из следующих способов: • преобразованием в "туннель" из круглых скобок; • добавлением новой стрелки, соединяющей соответствующий блок с границей диаграммы; • созданием внешней ссылки (ссылки на объект, не описанный в данной модели) в соответствии с методологией IDEFO; • созданием ссылки на блок, расположенный на другой диаграмме. В любой момент работы с диаграммой существует возможность добавления на нее новых блоков с использованием инструмента "Activity box Tool" панели инструментов. Для добавления блока необ­ ходимо щелкнуть на этом инструменте, а затем — на диаграмме в том месте, где необходимо расположить новый блок. После того как до­ полнительный блок создан, вы можете связать его стрелками с други­ ми блоками, задать его название и другие свойства. Нумерация блоков производится автоматически при их создании. Номера могут быть относительными или постоянными, они отражают иерархическое положение блока в пределах модели. Вы можете управлять нумерацией блоков на диаграмме, используя закладку "Presentation" диалога ввода свойств модели. Перемещение любых объектов на диаграмме осуществляется с по­ мощью их "захвата" мышью и перемещения в новое место. При пере­ мещении блоков одновременно перемещаются и связанные с ними стрелки. Функциональные блоки могут быть также перемещены меж­ ду диаграммами с использованием команд Cut/Paste из меню "Edit". Номера блокам диаграммы BPWin присваивает автоматически. При изменении взаимного расположения блоков эти номера могут изме­ няться. Изменение размеров объектов диаграммы может быть сделано пе­ ремещением их границ. Существует возможность запрета изменения размера объектов: это можно сделать на вкладке "Layout" диалога вво­ да свойств модели. Если включен просмотр дерева модели, существует возможность просмотра модели как дерева диаграмм или дерева функциональ­ ных блоков. Вершина дерева модели имеет кнопку переключателя Diagrams/Activities для отображения соответственно дерева диаграмм или дерева действий. Дерево диаграмм открывается по умолчанию при запуске BPWin. Дерево моделей BPWin использует специальный набор графических символов для представления диаграмм и действий в пределах дерева объектов. Вы можете использовать это дерево, что­ бы переключиться на соответствующую модель, диаграмму или дей­ ствие для выполнения редактирования. Использование цветовой палитры. В диаграмме BPWin Вы мо­ жете устанавливать цветовые свойства для действий, стрелок и тек­ стовых блоков. Использовать цвет в диаграммах не обязательно, но это может быть полезным: • для выделения недостаточно проработанных моментов; • для выделения внесенн^тх изменений; • для отображения похожих по смыслу объектов. Изменение цвета блоков диаграммы. Изменение цвета объекта Чтобы изменить цвет объекта, необходимо: • щелкнуть правой кнопкой мыши на объекте, выбрать в появив­ шемся меню пункт "Color editor"; • выбрать необходимый цвет объекта из предложенной палитры. Set Aclivily Colors Subpaiette: И TEXT Г* Text Color ^ Background Coh» Г Diagram Tide Color Г" Set as defadl for new acHvitie^. P^ Set for all occurrences of activi^. OK Cancel BiU New как тип, размер и стиль, могут использоваться для выделения или группировки функциональных блоков. Для изменения шрифта необ­ ходимо: • щелкнуть правой кнопкой мыши на объекте, выбрать в появив­ шемся меню пункт "Font editor"; • выбрать нужный шрифт и, при необходимости, задать его атри­ буты. Сделанные изменения можно применить и ко всем аналогичным объектам на диаграмме, включив соответствующие опции в левом нижнем углу окна диалога. Activity Name Font for* FcM^Stjib: Sm: jd . TrebuchelMS [^Verdana j ^ * Webdings l"^' Wingdings .-Effect- \ Г Stftoi* r Mnderi»» Г* Change el ectJvftief in the current diagrara Г Changea» of tNs: ront'fli the modei Курсив Полужирный . Полужирный K J Sample ' ЫФ PLATINUM BPwta Оформление стрелок. Использование стилей стрелок, применяе­ мых на диаграмме, важно для целостности и удобочитаемости созда­ ваемых диаграмм IDEFO. Вы можете изменять вид стрелок, устанав­ ливая их толщину, форму и цвет. Цвет стрелки устанавливается с использованием редактора цветов, как описано выше. Толщина стре­ лок также может быть изменена, что может применяться для вьщеле- ния отдельных процессов на диаграмме. Для изменения толщины стрелки необходимо: • щелкнуть правой кнопкой на стрелке и выбрать в меню пункт "Style editor"; • выбрать необходимую толщину стрелки в разделе "Thickness". Обратите внимание на то, что форма стрелки определена в соот­ ветствии с используемой методологией. Стрелки типа "Relational" не описаны в методологии IDEFO, но могут использоваться, если строгое следование IDEFO не обязательно. Диалог выбора вида и оформления IDEFO Arrow Properties ' Arrow Name: ;•' TnffikneS ^ "•'•• -••"••"• " -• • " ~ H^tences >! i П S^ thickness a$ default for ] ! Г" SellNcknesstoarfeiw j J new«row«. и г Set shape iodtro«»«egnient \ j „.^...«^ _,,_.^,,: J OK Отмена Справка Ветвление и объединение стрелок необходимо для обеспечения связи одной стрелки с несколькими функциональными блоками и на­ оборот. Объединенные стрелки используются для создания общего перехода от нескольких функциональных блоков к одному или к гра­ нице. Ветви и объединения создаются с использованием инструмента "Стрелка". Для удобства чтения диаграммы желательно именовать ка­ ждую ветку разделенной стрелки. Названия стрелок отображаются автоматически и могут быть пе­ ремещены с помощью "захвата" мышью. Для соединения стрелки с ее названием может бьггь использован инструмент "Squiggle" с панели Для прояснения содержимого диаграмм можно помещать на них текстовые блоки, содержащие произвольные пояснения. Для добавле­ ния текстового блока на диаграмму необходимо: • выбрать инструмент "Text" и нажать на том месте диаграммы, где необходимо разместить пояснения; • в появившемся текстовом окне необходимо ввести текст поясне­ ния. К текстовым блокам применимы все описанные выше инструмен­ ты оформления. Вы можете отображать Wm Щ^ШтЩр^^ ^iy^^^ft^g или скрывать определенные объекты диа­ граммы и отдельные элементы оформ­ ления. Например, Вы можете переклю­ чать тени функциональных блоков на диаграмме. Параметры меню "View" всем диаграммам Вашей модели. В этом же меню производится на­ стройка рабочего места BPWin. Напри­ мер, можно отобразить или скрыть стандартную панель инструментов, па­ нель инструментов "ModelMart", па­ нель инструментов "BPWin", дерево модели и строку состояния. Обратите внимание на пункт меню "Zoom", по­ зволяющий изменять масштаб про­ сматриваемых диаграмм. Этот пункт меню дублирует инструмент "Zoom" стандартной панели инструментов. В дополнение к контекстным диаграммам и диаграммам декомпо­ зиции другие типы диаграмм BPWin позволяют упростить представ­ ление и разработку модели. Например, может оказаться необходимым разработать сценарий "что-если" для модели. В этом подразделе будет рассмотрено создание двух типов мо­ делей: • диаграммы "только для представления" (For Exposition Only — FEO); • древовидные диаграммы. При правильном использовании эти типы диаграмм упрощают документирование моделей. Создание диаграмм FEO. Диаграмма FEO может быть использо­ вана для пояснени какой-либо части процесса, отраженрм особой точки зрения или выделения функциональных деталей, которые не­ возможно показать с использованием синтаксиса IDEFO. Они могут снабжаться дополнительным поясняющим текстом и не обязательно должны разрабатываться с учетом ограничений стандарта IDEFO. Диаграммы FEO могут быть ассоциированы с любой существующей в модели диаграммой, но не являются иерархической частью модели. Диаграмма FEO — копия любой существующей в модели диаграммы. Диаграмма идентифицируется с помощью: • задаваемого разработчиком имени; • идентификатора вида AxF, где х показывает исходную диаграмму, а символ F показывает, что диаграмма имеет тип FEO. FEO-диаграммы добавляются в модель с использованием пункта "FEO diagram" меню "Insert". В диалоговом окне "Create New FEO Diagram" выберите один из следующих типов диаграммы для копиро­ вания: • если Вы выбираете "Context", просто напечатайте имя новой диа­ граммы в поле "Name"; • если Вы выбираете "Decomposition", активизируется выпадаю­ щий список "Сору From", показывающий все диаграммы деком­ позиции в модели. После нажатия кнопки ОК будет создана и отображена на рабочем столе BPWin. Так же, как и для любой другой диаграммы, Вы можете открыть диалог ввода свойств FEO диаграммы для ввода ее свойств. Создание древовидных диаграмм (Node Tree Diagrams). Древо­ видные диаграммы используются для отображения структуры модели в целом. В них, как правило, вершина (самый верхний узел) соответст­ вует диаграмме контекстного уровня. Однако в качестве вершины мо­ жет быть использован любой функциональный блок модели, при этом его подблоки будут показаны в качестве ветвей дерева. Просмотр моделей с использованием древовидных диаграмм по­ зволяет акцентировать внимание на функциональной декомпозиции модели безотносительно к существующим внутри и вовне модели по­ токам. При изменении структуры модели древовидная модель пере­ страивается автоматически по мере внесения изменений в модель. Древовидные модели нумеруются по шаблону AxN аналогично диаграммам FEO. Древовидные диаграммы добавляются в модель с использованием пункта меню "Node tree" меню "Insert". При этом выводится диалого­ вое окно "Node tree definition", в котором задаются: • имя; • функциональный блок вершины; • количество уровней, на которые диаграмма показывается вниз; • параметры форматирования. После нажатия кнопки ОК древовидная диаграмма создается и вы­ свечивается на рабочем столе BPWin. Древовидные и FEO-диаграммы объединяются под названием "родственные" диаграммы. Они не отражаются непосредственно в де­ реве модели, однако дерево модели может быть использовано для их открытия. Для этого нужно, во-первых, переключить дерево модели в режим "Diagram view", а затем щелкнуть правой кнопкой мыши на на­ звании диаграммы. При этом BPWin выдаст соответствующий список родственных диаграмм. Для открытия родственных диаграмм также можно использовать инструмент "Sibling diagram tool" на панели ин­ струментов BPWin. Разбиение моделей в BPWin используется, как правило, для под­ держки коллективной разработки моделей. Единая модель может быть разделена на части, чтобы позволить нескольким разработчикам создавать собственные функциональные блоки модели. По заверше­ нии разработки разделенная на части модель может быть объединена в одну для отображения бизнес-процесса в целом. При разбиении мо­ делей на две каждая из них поддерживает собственный набор функ­ циональных блоков, стрелок и других объектов BPWin. Разбиение модели. Для разбиения модели на части необходимо придерживаться следующего алгоритма: • определите часть модели, которую необходимо отделить; • щелкните правой кнопко мыши на выбранном функциональном блоке; • выберите пункт меню "Split model"; • в диалоговом окне "Split options" введите имя, соответствующее имени функционального блока (использование этого имени по­ зволит впоследствии объединить модель); • включите опцию "Сору entire dictionaries", чтобы скопировать словари объектов в отделяемую часть модели; • нажмите кнопку ОК. В дереве модели будет создана и отображена новая модель. Обра­ тите внимание на следующие моменты: • блок, с которого производилось разбиение, становится диаграм­ мой контекстного уровня в новой модели; • в исходной связи появляется стрелка связи с именем, соответст­ вующим имени новой модели; • все дочерние диаграммы функционального блока перенесены в новую модель; • разбитый функциональный блок остается в исходной модели. После создания новой модели можно использовать диалог ввода свойств модели для определения свойств созданной модели. Объединение моделей. По завершении разработки разделенных моделей BPWin позволяет их объединение в одну. Для объединения моделей: • название стрелки связи должно соответствовать названию импор­ тируемой модели; • название функционального блока в контекстной диаграмме им­ портируемой модели должно соответствовать названию аналогич­ ного функционального блока в основной модели. При слиянии BPWin копирует все функциональные блоки, стрел­ ки и другую информацию (кроме контекстной диаграммы) из импор­ тируемой модели в основную. BPWin пропускает диаграмму контек­ стного уровня в импортируемой модели, поскольку она уже существует в основной модели. Все декомпозиции в импортируемой модели относятся в основной модели к целевому функциональному блоку. Целевой функциональный блок в основной модели всегда дол­ жен иметь исходящую из него стрелку связи. После открытия основной и импортируемой модели нужно: • щелкнуть правой кнопкой мыши на функциональном блоке основ­ ной модели, к которому нужно импортировать данные; • выбрать из меню пункт "Merge Model"; • диалог "Continue with merge?" подтверждает, что именн Вы хоти­ те объединить, и позволяет задать опции объединения. По завершении объединения можно заметить, что дерево модели обновляется для отражения изменений в основной модели. с использованием BPWin Добавление оценок к функциональным блокам BPWin обеспечи­ вает задание таких характеристик, как стоимость, время выполнения работы, метрики качества. Рассмотрим два метода задания этой ин­ формации: • задание оценок для функциональных блоков; • задание свойств блока, определяемых пользователем. Добавление стоимостных оценок для функциональных блоков ос­ новано на применении метода "Activity based costing" (ABC). Основ­ ная идея этой технологии состоит в задании оценки отдельных функ­ циональных блоков системы для получения суммарной оценки затрат на работу всей системы (модели). Затраты на работу родительских функциональных блоков, как правило, принимаются равными затра­ там на функционирование всех входящих в них подблоков. Таким об­ разом, ABC может использоваться для определения оценки затрат на функционирование системы в целом. Например, ABC может исполь­ зоваться для определения: • стоимости производимой продукции; • затрат на сервисные услуги; • затрат на предполагаемые изменения в технологии производства; • мест технологического процесса, требующих наибольших затрат. Технология ABC предполагает объединение затрат в "центры за­ трат" (под которыми понимается любой бизнес-процесс, функцио­ нальный блок или состояние системы, влияющие на стоимость функ­ ционирования системы) с последующим размещением стоимостей по объектам модели. Перед началом оценивания затрат необходимо убе­ диться, что существующая модель полна и устойчива. Оценивание функциональных блоков производится в три этапа: • определение единиц измерения; • определение "центров затрат"; • применение ценовых оценок к объектам модели. :..|. м -дайн» ' * ' .': • • Щ^ ц—- . ,^ ;,v , . ^-•> • \^^^ , jd^^:;;:/'vj\ •Tin*--: -'— J_. |;>;^„.,.„. i >Q»««»»»'..(' ^'^'^^fe-^^^,^ ^ измерения Выбор единиц измере­ ния. При установке единиц измерения необходимо вы­ брать вид валюты, который будет для этого использовать­ ся, а также определить вид представления денежных еди­ ниц на экране. Кроме того, нужно определить единицы времени, которые будут ис­ пользоваться (минуты, часы и т.п.). Эти параметры явля­ ются глобальными по отно­ шению к модели, задаются в закладе "ABC costs'* диалога задания свойств модели Определение "центров затрат" ("Cost Centers"). Далее необхо­ димо определить "центры затрат", которые будут использоваться. "Центры затрат" — это категории стоимости, которые будут при­ сваиваться функциональным блокам модели. Примеры "центров затрат": • маркетинг и реклама; • закупки комплектующих изделий; • техническая поддержка. "Центры затрат" задаются с использованием пункта "Cost center Ввод информации о затратах. Для каждого функционального блока модели Вы должны задать стоимость его работы. Какой бы ни была общая стоимость работы функционального блока, она должна состоять из затрат, определенных на предыдущем этапе при задании "центров затрат". Для этого используется Activity cost editor, вызывае­ мый из соответствующего меню при щелчке правой кнопкой мыши на блока определяются: • частота его выполнения; • продолжительность работы; • затраты на работу блока из "центра затрат". I Cost Cenlei Editor I Проведение рекламной кампании ш I O&ikution ш Detele I IDEFO Activity Properties СЬй Center IUB. Г fltverrfde decowpetioh* , fete» Шн Preouere^ >* |^ot($)(Je btstu dec^fjo^iDti^ Cc^ Center £<Ког^^. | йщ Общие затраты на работу функционального блока вычисляются автоматически, она показывается в левом нижне углу функциональ­ ного блока, для которого задана оценка затрат. Оценка затрат с использованием свойств, определяемых пользователем. Свойство, определяемое пользователем (User-defined property — UDP), создается для отображения произвольной инфор­ мации, относящейся к конкретному функциональному блоку или стрелке. BPWin поддерживает различные типы UDP, включая: • "выпадающие списки", например, для хранения информации об организации процесса или оценки его уровня; • исполнимые UDP, которые содержат ссылки на прикрепленные объекты, обрабатываемые другими программами; • текстовые списки, используемые, например, для хранения инфор­ мации типа "критических факторов успеха". UDP могут использоваться для более полной детализации модели и задания, например, таких свойств, как время, стоимость, качество и ответственные лица. UDP задаются с помощью пункта "User-Defined Property Name Editor" меню "Edit". Для этого нужно: • задать имя свойства; • назначить свойству тип данных; • при необходимости уточнить характеристики свойства (это нужно для некоторых типов данных). После создания UDP существует возможность присвоения им зна­ чений с помощью закладки "UDP values" диалога редактирования свойств функционального блока или стрелки. После того как Вы создали модель, Вы захотите продемонстриро­ вать ее другим на бумаге. BPWin поможет Вам в этом с помощью раз­ нообразных функций для печати диаграмм. Некоторые из них: • выбрать диаграмму (или диаграммы), которую Вы хотите напе­ чатать; • включить сообщения диаграммы с распечатками диаграммы; • включить родительскую диаграмму для диаграммы, которую Вы будете печатать; • определить спецификацию диаграммы для печати: цветовая гам­ ма, внешние границы диаграммы; • отправить диаграмму в файл для последующей печати; • определить, как печатать диаграммы: каждая диаграмма н одном листе по выбору, пакетная печать всех диаграмм модели с указа­ нием количества их на листе. Вы можете печатать диаграммы BPWin из меню Печати Диаграм­ мы BPWin, которое может быть открыто из меню "File" командой "Print" или нажатием изображения принтера в панели инструментов мянутые ранее. А-и. Untitled и (Contexf i AOD УпЫМIfDFD) ШЩ Ш Как Вы уже смогли понять, вид напечатанной модели зависит от выбора опций печати, которые Вы установили. Вы можете поэкспери­ ментировать перед печатью для определения, какие установки работа­ ют лучше для вашего случая. BPWin предоставляет набор отчетов для публикации информа­ ции, которая помещена в Вашу модель. Существуют средства на­ стройки отчетов. Отчеты BPWin разделяются на стандартные и нестандартные. От­ личие их заключается в том, что для получени стандартного отчета не требуется задания никаких дополнительных параметров. Для полу­ чения нестандартного отчета необходимо указать объекты, которые должны быть отражены в отчете. Перечислим стандартные отчеты BPWin: • отчет по диаграммам (diagram report) — включает информацию об объектах в активной диаграмме BPWin; • отчет о стрелках (arrow report) — включает информацию о стрел­ ках (связях) в BPWin модели; • отчет о затратах (activity cost report) — содержит информацию о затратах функциональных блоков и о "центрах затрат" в BPWin модели; • отчет об объектах диаграммы (diagram object report) — содержит информацию об объектах, размещенных на диаграмме (функ­ циональных блоках, хранилищах данных и внешних ссылках) в BPWin-модели; • отчет об использовании данных (data usage report) — содержит ин­ формацию о таблицах базы данных или сущностях и атрибутах; • отчет о целостности модели (model consistency report) — содержит информацию о том, насколько активная IDEFO-модель соответст­ вует выбранной IDEFO-методологии; • отчет о модели (model report) — содержит общую информацию от­ дели может включать один элемент или большее количество эле­ ментов, указанных в диалоговом окне Model Definition Editor. Для получения отчета необходимо проделать следующие основ­ ные шаги: • выбрать нужный отчет в меню Reports; • выбрать элементы модели, которые необходимо включить в отчет • выбрать, куда нужно вывести сформированный отчет. Рассмотрим более сложный отчет, например отчет об объектах много больше параметров, чем в предыдущем примере. Сложность отчета определяется количеством данных, которые нужно отразить в отчете. Для выполнения отчета об объектах диаграммы нужно: • определить объекты диаграммы и степень детализации отчета; Diagram Object Report Standanl^ir Moctei: rt Г" Datd^ores Г* Ейета! References Start РшйГ f* fiorrstraint* ..r l i r lijpiiHame t Г Input DeWfon , r QonMNerim ' П CdnlfdDefinto» П Dti^yrNaise П Met^Name ^ P Mech Degntoi P C«IMt«?#l^affie П CaKMowOefffntion Report Format <*^ Labefesd С Feted СЫигйп Г lab Delimited <^ Comma Deiwted ГдОЕТаЫе M*ValuedFofmefc--^ P BepeatNi^roup i ^r Eited . '; ~ ^ j F Remove Special Char: Activity Ordering -. Г Alphafertical j <^ Hlerar<#ial . j Г BreadthFir^ , J "Airow Orderbi --^ Г j^k^Nabetical ^ \ ^ ArrowNiirriier j • выбрать элементы данных, которые нужно включить в отчет (об­ ратите внимание, что можно включать в отчет определяемые пользователем свойства — UDP); • определить дополнительные параметры форматирования для пе­ чати или имена дисковых файлов; • определить, как данные отчета будут упорядочены. BPWin устанавливает набор предопределенных отчетов, которые указаны как "стандартные" отчеты. Это отчеты с заранее выбранными параметрами, подходящими для большинства пользователей. Не все отчеты BPWin имеют стандартную форму. Стандартные жав на кнопку раскрытия списка. Вы будете видеть набор имеющихся стандартных отчетов. в дополнение к имеющимся в BPWin Вы можете определять и со­ хранять ваши собственные отчеты следующим образом: напечатать название в соответствующем поле, выбрать параметры отчета, нажать кнопку New. Определение отчета будет сохранено, добавлено к спи­ ску для использования в следующий раз. Кнопки Update и Delete позволяют изменять существующие пара­ метры отчета или удалять созданные отчеты. При разработке модели одним из наиболее полезных является от­ чет о ее целостности. Он содержит информацию о том, как хорошо Ва­ ша модель соответствует выбранной IDEFO методологии. Это помога­ ет следить за соблюдением методологии и выявлять любые нарушения целостности модели. При выборе отчета о целостности модели из меню Report BPWin отображает соответствующий диалог, не имеющий никаких парамет­ ров. BPWin автоматически генерирует отчет, когда Вы нажимаете кнопки Предварительного просмотра. Печати или Report. Итак, в этой главе мы познакомились с программным средством Platinum BPWin — наиболее распространенным сегодня пакетом, набор функций этой программы позволяет применять ее для разработ­ ки программного обеспечения корпоративных информационных сис­ тем и для решения задач по реинжинирингу бизнес-процессов. ГЛАВА ПРАКТИЧЕСКИЕ ЗАНЯТИЯ В качестве примера рассмотрим деятельность вымышленной сборкой и продажей настольных компьютеров и ноутбуков. Годовой купает компоненты для компьютеров от трех независимых постав­ щиков, а не производит компоненты самостоятельно. Она только собирает и тестирует компьютеры. Компания реализует продукцию через магазины и специализируется на покупателях, для которых главный критерий при покупке — стоимость компьютера. Предпо­ Несмотря на некоторое увеличение объема продаж, прибыли уменьшаются, растет конкуренция на рынке. Чтобы не потерять пози­ ции, компания решает проанализировать текущие бизнес-процессы и реорганизовать их с целью увеличения эффективности производства и продаж. Основные процедуры в компании таковы: • продавцы принимают заказы клиентов; • операторы группируют заказы по типам компьютеров; • операторы собирают и тестируют компьютеры; • операторы упаковывают компьютеры согласно заказам; • кладовщик отгружает клиентам заказы. В настоящее время компания Quill использует купленную бухгал­ терскую информационную систему, которая позволяет оформить за­ каз, счет и отследить платежи по счетам. Улучшение деятельности компании должно касаться структуры управления компанией, эффективности производства и внутреннего контроля. В результате реорганизация может потребовать внедрения новой корпоративной информационной системы (состоящей не толь­ ко из одного бухгалтерского модуля). Однако перед тем как пытаться производить какие-то улучшения, необходимо разобраться в существующих бизнес-процессах. Для создани контекстной диаграммы выполните следующи дей­ ствия. Нажмите на кнопку Cancel. {Деятельность компании Quill} и выберите Туре — IDEFO. Нажмите кнопку ОК. тов. Эта кнопка включает и выключает инструмент просмотра и навигации — Model Explorer (появляется слева). Кнопка Activities/Diagrams переключает режим Model Explorer. В режиме Activities щелчок правой кнопкой по объекту в Model Explorer позво­ ляет редактировать его свойства. диалогового окна Model Properties следует внести имя модели {Дея­ тельность компании Quill}, имя проекта {Модель деятельности Quill}, имя автора и тип модели — Time Frame {AS-IS}. щие (AS-IS) бизнес-процессы компании Quill} и Точку зрения {Viewpoint: Директор}. дель, описывающая деятельность компании Quill} и Scope {Общее управление бизнесом компании: исследование рынка, закупка компо­ нентов, сборка, тестирование и продажа продуктов}. ОК. ства диаграммы. цы для печати диаграммы. В этом диалоговом окне устанавливается "логический" размер страницы. Если принтер не поддерживает такой размер, диаграмма может быть разбита на несколько страниц. щелкните по работе. В контекстном меню выберите Name Editor. В за­ кладке Name внесите имя {Деятельность компании Quill}. процессы компании Quill}. щелкните по ОК. Контекстная диаграмма Бухгалтерская система Звонки клиентов Правила и процедуры Проданные продукты Описание Оформление счетов, оплата счетов, ра­ бота с заказами Запросы информации, заказы, техни­ ческая поддержка и т.д. Правила продажи, инструкции по сбор­ ке, процедуры тестирования, критерии производительности и т.д. Настольные и портативные компью­ теры Тип Mechanism Input Output С помощью кнопки j ^ внесите текст в поле диаграммы — точку зрения и цель. Report. tffllffllfHHl oil /yiewpojrt .a : Директор ^ il.-^..,-^ „ OK I Drtod I ^ S S ^ B«po« ^i i » НФ ll Цат Фт ^ iScope: Оваее управление виэнесои конпаиии: исГ тестирование и продаже продуктов X Uiewpoint: Viewpoint: Директор TiPie Frane: («S-IS) , Status: WORKING Propouse: Propouse: Моделировать текуцие (ftS-:> бизнес процессы компании Quill ^ Source: Материалы курса по BPqwin Duthof* Маме: Ваше имя - Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: декомпозиции I. Выберите кнопку перехода на нижний уровень в палитре инст­ рументов, в диалоговом окне Activity Box Count установите число ра­ i^labloUlTloUUnF Achvily Box Count QK л СлксЫ J ' 'Hel> Автоматически будет создана диаграмма декомпозиции. Правой кнопкой мыши щелкните по работе, выберите Name Editor и внесите имя работы. Повторите операцию для всех трех работ. Затем внесите Описание работ для диаграммы декомпозиции Функциональный Продажи, Сборка, тестирование компьютеров OxqjysKa, получение Описание Телемаркетинг, презен­ тации, выставки Сборка и тестирование настольных и портатив­ ных компьютеров Отгрузка заказов клиен­ там и получение компо­ нентов от поставщиков Статус WORKING WORKING WORKING Источник Материалы курса BPWin Материалы курса BPWin Материалы курса BPWin cl Diclionaru Editor Зарегистрировать ^шшшт--вттт:^ явш 'НОВОГО владельца компании Jii Щй^^ Ш ф«} < -&S^^'^'<'P'i \\ ^f^ l Если Вы опишете имя и свойства работы в словаре, ее можно бу­ дет внести в диаграмму позже с помощью кнопки Ш| в палитре инст­ рументов. Вы не можете удалить работу из словаря, если она исполь­ зуется на какой-либо диаграмме. Если Вы удалите работу из диаграммы, из словаря она не удаляется. Имя и описание такой рабо­ ты может быть использовано в дальнейшем. Для добавления работы в словарь щелкните по кнопке Clear, внесите имя и свойства работы, за­ тем щелкните по Add. Для удаления всех имен работ, не использую­ щихся в модели, щелкните по Pm*ge. стрелки (кнопка ^ д на палитре инструментов) с остальными так, как Звонки клиентов Правила и процедуры Продажи и маркетинг Сборка и тестирование компьютеров рт Отфузка и получение Проданные продукты Бухгалтерская система работы "Сборка и тестирование компьютеров" и переименуйте ее в Внесите определение для новой ветви: "Инструкции по сборке, процедуры тестирования, критерии производительности и т.д." Звонки клиентов Правила и процедуры Продажи и маркетинг to^ Правила сборки и тести­ рования Сборка и тестирование компьютеров Система оформления заказов Правой кнопкой мыши щелкните по ветви стрелки механизма ра­ боты "Продажи и маркетинг" и переименуйте ее в "Систему оформле­ ния заказов". пользование словаря стрелок (вызов словаря — меню Edit / Arrow Dictionary). Если Вы опишите имя и свойства стрелки в словаре, ее можно будет внести в диаграмму позже. Вы не можете удалить стрел­ ку из словаря, если она используется на какой-либо диаграмме. Если Вы удалите стрелку из диаграммы, из словаря она не удаляется. Имя и описание такой стрелки может быть использовано в дальнейшем. Для Продажи и маркетинг Заказы клиентов Правила сборки и тести­ рования Сборка и тестирование компьютеров Собранные компьютеры Отгрузка и получение добавления стрелки в словарь щелкните по кнопк Clear, внесит имя и свойства работы, затем щелкните по Add. Для удалени всех имен стрелок, не использующихся в модели, щелкните по Purge Unused. рование компьютеров" к работе "Продажи и маркетинг". Для большей наглядности измените стиль стрелки (толщина линий) и установите опцию Extra Arrowhead (из контекстного меню). Методом drag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите Squiggle (из контекстного меню). ' ' \ / Продажи и маркетинг i \ Заказы клиентов ' ' ^ Правила сборки j и тести­ рования ' Сборка и тестирование компьютеров Резуль­ таты сборки и тести­ рования материалы" из работы "Продажи и маркетинг". Эта стрелка автомати­ чески не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике g^. Из палитры выберите кнопку ()|, щелкните мышью по квадратным скобкам и в диалоговом окне Border Arrow Editor выберите Resolve Border Arrow. Для стрелки "Маркетинговые материалы" выберите опцию Trim из контекстного меню. Проверить правильность выполнения задания можно с использо­ ванием файлов, полз^енных из Интернета: декомпозиции Декомпозируется работа "Сборка и тестирование компьютеров". В результате проведения экспертизы получена следующая инфор­ мация: • производственный отдел получает заказы клиентов от отдела про­ даж по мере их поступления; • диспетчер координирует работу сборщиков, сортирует заказы, группирует их и дает указание на отгрузку компьютеров, когда они готовы; ных компьютеров и ноутбуков и направляет на участок сборки; • сотрудники участка сборки собирают компьютеры согласно спе­ цификациям заказа и инструкциям по сборке. Когда группа ком­ пьютеров, соответствующая группе заказов, собрана, она на­ правляется на тестирование. Тестировщики тестируют каждый компьютер и в случае необходимости могут заменить неисправ­ ные компоненты; • тестировщики направляют результаты тестирования диспетчеру, который на основании этой информации принимает решение о передаче компьютеров соответствующей группы заказов на отгрузку. На основе этой информации внесите новые работы и стрелки Описание бизнес-процессов для работы "Сборка и тестирование компьютеров'' Функциональный блок Отслеживание рас­ писания и управле­ ние сборкой и тес­ тированием Сборка настоль­ ных компьютеров Описание Просмотр заказов, установка расписания выполнения заказов, просмотр результатов тестирования, формирование групп заказов на сборку и отгрузку Сборка настольных компьютеров в соот­ ветствии с инстрзосциями и указаниями диспетчера Статус WORKING WORKING Продолэюение Функциональный блок Сборка ноутбуков ! Тестирование ком­ пьютеров Описание Сборка ноутбуков в соответствии с инст­ рукциями и указаниями диспетчера Тестирование компьютеров и компонент. Замена неработающих компонент. Статус WORKING WORKING Описание стрелок для декомпозиции работы ^Сборка и тестирование компьютеров'^ Стрелка Диспетчер Заказы клиентов Заказы на настольные компьютеры Заказы на ноутбз^си Компоненты Источник Персонал произ­ водственного отдела {Border} Отслеживание расписания и управление сборкой и тестированием Отслеживание расписания и управление сборкой и тестированием { Tunnel} Сборка настоль- ных компьютеров | Тип Mechanism Control Output Output Input Output Назначение Отслеживание расписания и управление сборкой и тестированием Отслеживание расписания и управление сборкой и тестированием Сборка настоль­ ных компьютеров Сборка ноутбуков Сборка настоль­ ных компьютеров Сборка ноутбуков Тестирование компьютеров Тестирование компьютеров Тип наз- Mechanism Control Control Input Input Продолжение Стрелка Ноутбуки Персонал про- изводствен- Правила сбор­ ки и тес- Результаты сборки и тес- Результаты тестирования Собранные компьютеры Тестировщик Указание пе­ редать ком­ пьютеры на отп^узку Источник Сборка ноутбуков { Tunnel} Правила и процедуры Сборка настоль­ ных компьютеров Сборка ноутбуков Тестирование компьютеров Тестирование компьютеров Тестирование компьютеров Персонал произ­ водственного от­ дела Отслеживание расписания и уп­ равление сборкой и тестированием | Тип Output Mechanis m Control Output Output Output Output Output Output Назначение Тестирование компьютеров Сборка настоль­ ных компьютеров Сборка ноутбуков Сборка настоль­ ных компьютеров Сборка ноутбуков Тестирование кoмпьютepQв { Border } Отслеживание расписания и управление сборкой и тестированием { Border } Тестирование компьютеров Тестирование компьютеров Тип наз- Input Mechanism Mechanism | Control Control Control Input Mechanism Control Туннелируите и свяжите на верхнем уровне граничные стрелки, если это необходимо. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Ill mill — Diagram Н^мм*^ [Деятельность KOMnBMAtCMI. компании QuiH i^l^mpc ^)uih<)fN«Mi:.| •I <^рЙкШ \ ГдйАРТ ', -•" ,„„„„„,„„„„„„„„,„„•„„„„„„„„„,„• Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: дерева узлов Для проведения деловой встречи директору компании необходи­ мо иметь общую картину происходящих в компании бизнес-процес­ сов. Создайте диаграмму дерева узлов. Установите фокус на диаграмме дерева узлов, перейдите в меню Edit / Diagram Properties, в закладке Style диалогового окна Node Tree Properties отключите опцию Bullet Last Level. Щелкните по кнопке ОК. Посмотрите результат. При обсуждени бизнес-процессов возникла необходимость де­ тально рассмотреть взаимодействие работы "Сборка и тестирование компьютеров" с другими работами. Чтобы не модифицировать диа­ грамму декомпозиции, создайте FEO-диаграмму, на которой бу­ дут только стрелки работы "Сборка и тестирование компьютеров" имя диаграммы FEO. Щелкните по кнопке ОК. Properties и в закладке Diagram Text внесите определение. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: i к Продажи и маркетинг ' Заказы клиентов Сборка и тестирование компьютеров Рис Результаты сборки и тестирования Собранные компьютеры Отфузка и получение FEO-диаграммы в результате проведения экспертизы от сотрудников производст­ венного отдела получена дополнительная информация — оказалось, что неисправные компоненты направляются на отгрузку. Для уточне- ния информации необходима дополнительная экспертиз в отделе от­ грузки. Создайте FEO для проведени такой экспертизы. Постройте FEO на основе диаграммы АО и добавьте стрелку "Неисправные компоненты". Стрелка должна идти с выхода "Сбор- ка и тестирование компьютеров" на вход "Отгрузка и получение" Правила и процедуры Звонки клиентов Продажи и маркетинг Заказы клиентов Правила сборки и тести- Сборка и тестирование компьютеров Резуль­ таты сборки и тести­ рования Собранные компьютеры Неисправные компоненты Маркетинговые материалы Отгрузка и получение Проданные продукты Бухгалтерская система Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: моделей Расщепление модели: по работе "Сборка и тестирование компьютеров" и выберите Split model. "Сборка и тестирование компьютеров", установит опции, как на Split Options tJjBw Model Name: |Сборка и тестирование компьютеров OK Csncd Нф модель, на диаграмме АО модели "Деятельность компании Quill" поя­ вилась стрелка вызова "Сборка и тестирование компьютеров". зрения. Цель: документировать работу по сборке и тестированию компью­ теров. Точка зрения: Директор. граничная стрелка выхода, на диаграмме АО — граничная стрелка вы­ хода от работ «Сборка настольных компьютеров», «Тестирование компьютеров» и «Сборка ноутбуков». Слияние модели: Quill". вание компьютеров" и выберите Merge model. Dictionaries и щелкните по кнопке ОК. Посмотрите на результат. В Model Explorer видно, что две модели слились. Модель "Сборка и тестирование компьютеров" осталась и может быть сохранена в отдельном файле. На диаграмме АО модели "Деятельность компании Quill" исчезла стрелка вызова "Сборка и тес- тирование компьютеров". Появилась неразрешенная гранична стрел­ ка "Неисправные компоненты". Направьт эту стрелк к вход работы "Отгрузка и получение". Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: стольных компьютеров". В диалоговом окне Activity Box Count уста­ держащая работы (UOW). Правой кнопкой мыши щелкните по работе, выберите в контекстном меню Name Editor и внесите имя работы — "Под­ готовка компонент". Затем в закладке Definition внесите определение "Под­ готавливаются все компоненты ком­ пьютера согласно спецификации за­ каза". В закладке UOW внесите следую­ щую информацию: АсЙуЙуВохСоагй Objects Компоненты: винчестеры, корпуса, материнские платы, видео­ карты, звуковые карты, дисководы CD-ROM и флоппи, модемы, программное обеспечение Constrains Установка модема требует установки дополнительного програм­ много обеспечения Внесите другие имена работ: • установка материнской платы и винчестера; • установка модема; • установка дисковода CD-ROM; • установка флоппи-дисковода; • инсталляция операционной системы; • инсталляция дополнительного программного обеспечения. с помощью кнопки палитры инструментов создайте объект ссылки. Внесите имя объекта внешней ссылки —"Компоненты". Свяжите стрелкой объект ссылки и работу "Подготовка компо­ нентов". Свяжите стрелкой работы "Подготовка компонентов" (выход) и "Установка материнской платы и винчестера". Измените стиль стрел­ мает отсутствие имени как ошибку. Компоненты Подготовка компонентов Установка материнской платы и винчестера | Установка флоппи- дисковода Г" Установка дисковода CD-ROM Установка модема Инсталляция операционной системы Инсталляция дополнительного профаммного обеспечения Сохраните модель. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: с помощью кнопки Ш\ на палитре инструментов внесите два перекрестка типа "асинхронное или" и свяжите работы с перекрест­ Правой кнопкой щелкните по перекрестку для разветвления (fan- out), выберите Name Editor и внесите имя "Компоненты, требуемые в Установка материнской платы и винчестера Установка флоппи- дисковода Л Установка дисковода CD-ROM Установка модема Инсталляция операционной системы Создайте два перекрестка типа "исключающее или" и свяжите ра­ Компоненты Подготовка компонентов Установка материнской платы и винчестера Установка I флоппи- '^ дисковода Л Установка дисковода CD-ROM Установка ^ модема О М Инсталляция операционной системы Инсталляция дополнительного профаммного обеспечения ы Профаммное обеспечение Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: в результате проведения экспертизы с тестировщиками выявлена следующая информация: • каждый тестировщик имеет собственную периферию (монитор, клавиатуру, мышь) для проверки компьютера; • каждый тестировщик подсоединяет кабель питания и периферию для настольного компьютера и кабель питания для ноутбука; • каждый тестировщик запускает с дискеты программу диагности­ ки, которая тестирует компоненты компьютера; • если программа диагностики определяет неработающий компо­ нент, тестировщик заменяет его исправным. Тестирование и заме­ на компонентов проводится до тех пор, пока все компоненты ком­ пьютера не будут исправлены; • каждый проверенный компьютер хранится до тех пор, пока дис­ петчер не даст распоряжение об отгрузке партии; • неисправные компоненты направляются на отгрузку для возврата поставщикам. На основании этой информации необходимо декомпозировать (в Создайте UOW: • подключение периферии; • запуск программы диагностики; • формирование партии; • замена неисправных компонентов. Создайте четыре объекта ссылок: • периферия; • компьютер; • заказы; • компоненты. Соедините работы и объекты ссылок стрелками, как показано на Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Периферия Заказы Исправные компьютеры Vr- Подключение периферии Компьютер I/' Запуск программы —J |х Формирование партии Неисправные компьютеры Замена неисправных компонентов Починенный компьютер Компоненты Выберите пункт меню Insert / FEO Diagram. Компоненты Подготовка компонентов Установка материнской платы и винчестера л у Установка модема —И [о Инсталляция операционной системы Программное обеспечение Инсталляция дополнительного программного обеспечения Удалите элементы, н входящи в сценарий. Проверить правильност выполнения задани можно с использо­ ванием файлов, полученных из Интернета: нентов. В сценарий должны входить только объекты, содержащие Периферия Подключение периферии Компьютер |х Запуск программы диагностики Неисправные компьютеры V. |х л U неисправных компонентов | Компоненты Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: начало — файл OSd.bpl, окончание — файл OSs.bpl. Исходные данные для анализа (Activity Based Costing). ровщик. Двое сборщиков являются стажерами. Средняя стоимость компонентов для настольного компьютера со­ закладке ЛВС Units установите единицы измерения денег и времени. Cost Centers внесите название и определение центров затрат. Центр затрат Определение Управление Затраты на )щравление, связанные с составлением графика работ, формированием партий компьютеров, контролем над сборкой и тестированием Рабочая сила Затраты на оплату рабочих, занятых сборкой и тестированием компьютеров Компоненты Затраты на закупку компонентов ние и щелкните по кнопке Add. Стоимость каждой работы отображается в нижнем левом углу прямоугольника. Для отображения частоты или продолжительности работы перей­ дите в диалоговое окно Model Properties, закладка Display и переклю­ чите радиокнопки в группе ABC Units. Вы можете вообще отключить режим отображения информации об ABC, отключив опцию Activity Cost/Freq/Dur. в диалоговом окне Model Properties или меню View шщ Для указани стоимости работы следует щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню Cost Editor. Параметры ЛВС для назначения стоимости работы Функциональный блок Отслеживание расписа­ ния и управление сбор- Сборка настольных ком- Тестирование компью­ теров Cost Center Управление Рабочая сила Компоненты Рабочая сила Компоненты Рабочая сила Затраты Продолжи­ тельность Частота Посмотрите результат — стоимость работы верхнего уровня. Сгенерируйте отчет Activity Cost Report. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Определите стоимость работы "Отгрузка и получение". Создайте центр затрат "Транспортные расходы". Подсчитайте и назначьте стоимость работе "Отгрузка и по­ Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: ПО Выполните следующи действия. Member внести наименование категории и щелкнуть по кнопке Add Сд^евдбНсй^ ^ '-^^'::ттгШ ^ ^w-; ':'^^гт Information system Qualitv measure Resources consumption \j|«ifCAsee^<^^ • Resources Consumption (расход ресурсов); • Documentation (документация); • Information System (информационная система); • Quality Measure (мера измерения качества). be added after selected property внесите имя UDP, например, "Quality". Затем выберите тип UDP из комбобокса Datatype — "Text List (Single selection)", после чего щелкните по кнопке Add. New Category/Member внесите значение "A-Terrific" и щелкните по кнопке Add Member. Затем внесите другие значения UDP Quality: • B-Good; . С-ОК; • D-Poor; • E-Awfiil. тем щелкните по категории в нижнем списке, после чего щелкните по кнопке Update. Список UDP для модели Наименование UDP Application (приложения) Screen Additional Documentation (дополнитель­ ная докумен- Change History (история изме­ нения) Electricity Consumption (расход элек­ троэнергии) Тип Text List (Mul­ tiple Selection) Command Command List Paragraph Text Real Number Члены COS — Customer Order System (модуль оформления заказов) ESS — Employee Sheduler Sys­ tem (модуль создания и конт­ роля расписания выполнения работ) PIS — Parts and Inventory Sys­ tem (модуль учета комплекту­ ющих и оборудования) PTS — Procedures and Trouble­ shooting System (модуль про­ цедур сборки и поиска неис­ правностей) Winword.EXE samplel.doc POWERPNT.EXE sampleS.ppt Категория Information System Information Documentation Documentation Resources Consumption Функцио­ нальный блок Отслежива­ ние расписа­ ния и управ­ ление сбор- ' кой и тести­ рованием Значения UDP для модели Дополни­ тельная док)^ентация Winword.EXE Приложение COS — Cus­ tomer Order System ESS — Employee Sheduler System История изменений История из­ менения специфика­ ций Потреб­ ление энергии Качество B-Good Продолэюение Функцио­ нальный блок Дополни­ тельная документация Сборка настольных компью­ теров Сборка ноутбуков Тестирование компьютеров Приложение История изменений PIS — Parts and Inventory System PTS — Procedures and Troubleshooting System PIS — Parts and Inventory System PTS — Procedures and Troubleshooting System PIS — Parts and Inventory System PTS — Procedures and Troubleshooting System Потреб­ ление энергии Качество A-Terrific с-ок по кнопке ^^ приведет к запуску приложения. кнопке Categories. В появившемся новом диалоговом окне Activity Categories Editor отключите категорию Information System. Щелкните по кнопке ОК. Посмотрите результат. кам. Щелкните по стрелке правой кнопкой и выберите в контекстном меню UDP Editor. Задайте значения UDP следующим стрелкам: Наименование стрелки Качество Заказы на настольные компьютеры B-Good Ноутбуки B-Good Собранные компьютеры A-Terrific Report. Выберите опции отчета: User Defined Properties: Electricity Consumption. Report Format: RPTwin. "Сохранение файла" щелкните по кнопке "Сохранить". Запускается генератор отчетов RPTwin и появляется диалоговое rlS<jidtfliiM»'rn^ ЭЭРАСТООв «t Т ^^«tiitttyNMte •i_J Нажатие на кнопку "Предварительный просмотр" позволяет про­ смотреть отчет. Отразите в отчете суммарный расход электроэнергии. кер в секцию отчета Page Footer, после чего щелкните один раз. Появ­ Sum ({Electricity Consumption}) т Fennufa: Sum ({Electricity Consumption}) ^dMty Name lSi^( NUMBER?) Sin f NUMBER?! Tan (NUMBER?) TkneO ToDate {DATETIMESTR?. FOR-» ToNunAe(( STRING?) jjj €Ш^ Cut |/\' ^t-^^^t^'^t-^l^/t^: ЙК Просмотрите отчет. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Задание. Использование Категории UDP Responsibility (ответствен­ ность) Customer Satisfaction (оцен­ ка клиента) Тип Text List (Single Selection) Integer List (Single Selection) Члены Ivanov Petrov Sidorov Категория Quality Measure Quality Measure Свойства работ UDP Функциональный блок Отслеживание расписания и управ­ ление сборкой и тестированием Сборка настольных компьютеров Сборка ноутбуков Тестирование компьютеров Ответственный Манышкин Морковин Нечаева Шобанов Удовлетворенность заказчика Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Перейдите на диаграмму АО и щелкните правой кнопкой мыши по работе "Отгрузка и получение". В контекстном меню выберите Split Model. В появившемся диалоговом окне Split Option установите опцию Enable Merge/Overwrite Option, внесите имя новой модели — "Отгруз­ ка и получение" и щелкните по кнопке ОК. Обратите внимание, что у работы "Отгрузка и получение" появи­ лась стрелка вызова. BPWin создал также новую модель "Отгрузка и получение". Внесите свойства новой модели: • Time Frame: AS-IS; • Рпфозе: документировать работу "Отгрузка и получение"; • Viewpoint: начальник отдела; • Definition: модель создается для иллюстрации возможностей BPWin по расщеплению и слиянию моделей; • Scope: работы по получению комплектующих и отправке готовой продукции. Декомпозируйте контекстную работу на следующие работы. функциональный блок Описание Получить комплектующие Физически получить комплектующие и сделать соответствующие записи в информационной сис­ теме Доставить комплектующие Доставить комплектующие сборщикам и тести- ровщикам Отгрузить товар и возврат Отгрузить товар клиентам и неисправные компоненты (возврат) поставщикам. Правила и процедуры Получить комплектующие Доставить комплектующие Неисправные компоненты Собранные компьютеры ^ Отгрузить товар и возвратить Проданные продукты Бухгалтерская система Внесите следующие внутренние и граничные стрелки: Наименование Описание Возврат поставщику Неисправные компоненты Компоненты Выберите название из списка (словаря) Компоненты от поставщика Выберите название из списка (словаря) Проверенные компоненты Проверенные и подготовленные для передачи сборщикам и тестировщикам компоненты. Туннелируйте граничные стрелки (Resolve Border Arrow) — Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Компоненты от поставщика Правила и процедуры Получить комплектующие Неисправные компоненты Собранные компьютеры Доставить комплектующие Бухгалтерская система Компоненты Отгрузить товар и возвратить Проданные продукты _ Возврат поставщику с исходной («as is») моделью Выполните следующие действия. грамме АО щелкните правой кнопкой мыши по работе "Отгрузка и по­ лучение". В контекстном меню выберите Merge Model. вите опцию Paste/Merge entire dictionaries и щелкните по кнопке ОК. чезла стрелка вызова и появилась новая декомпозиция. руйте эти стрелки (Resolve Border Arrow). Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Звонки клиентов Правила и процедуры Продажи и маркетинг Компоненты от поставщика Заказы клиентов Правила сборки и тести­ рования Сборка и тестирование компьютеров Резуль­ таты сборки и тести­ рования Собранные компьютеры Неисправные компоненты Маркетинговые материалы Отфузка и получение Возврат поставщику Проданные продукты ^ Бухгалтерская система Создайте новую модель "ТЕСТ". Декомпозируйте контекстную работу в новой модели, но не вносите имена работ. Переключите Model Explorer в режим Activity. Используя drag&drop, перенесите какую-нибудь работу из модели "Деятель­ ность компании Quill" на диаграмму декомпозиции модели "ТЕСТ". В появившемся диалоговом окне Continue with Merge? установите опцию Paste/Merge entire dictionaries и щелкните по ОК. Посмотрите результат. Щелкните по работе в модели "ТЕСТ" и переместите работу на место неназванной работы на другой диаграмме. В появившемся диа­ логовом окне Continue with Merge? щелкните по ОК. Посмотрите ре­ зультат. Закройте модели без сохранения. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: («to-be») модели Оценка бизнес-процессов модели AS-IS показала недостаточную эффективность деятельности компании Quill. В первую очередь это касается производственного отдела. Собираемые компьютеры не все­ гда пользуются достаточным спросом. Закупаемые компоненты часто чрезмерно дороги при посредственном качестве. Функциональность компьютеров не соответствует требованиям рынка. В результате анализа компания принимает решение реорганизо­ вать функции производства и тестирования компьютеров. Кроме того, принимается решение оставить функциональность "Продажи и мар­ кетинг" и "Отгрузка и получение" пока без изменений. Принято решение сформировать отдел дизайна, который должен формировать конфигурацию компьютеров, разрабатывать корпора­ тивные стандарты, подбирать приемлемых поставщиков, разрабаты­ вать инструкции по сборке, процедуры тестирования и устранения не­ поладок для всего производственного отдела. Работа "Сборка и тестирование компьютеров" должна быть реор­ ганизована и названа "Производство продукта". Сначала мы создадим работы "Разработать конфигурацию", "Планировать производство" и "Собрать продукт". Рассмотрим новые роли персонала: • дизайнер должен разрабатывать систему; ментировать и передавать спецификации в отдел маркетинга и продаж; • дизайнер должен определять, какие компоненты (software и hardware) должны закупаться для сборки компьютеров; • дизайнер должен обеспечивать документацией и управлять про­ цедурами сборки, тестирования и устранения неполадок. Функции диспетчера в работе "Сборка и тестирование компьюте­ ров" должны быть изменены: • диспетчер должен обрабатывать заказы клиентов и генерировать заказы на сборку; • диспетчер должен получить коммерческий прогноз из отдела мар­ кетинга и формировать требования на закупку компонент; • диспетчер должен собирать информацию от поставщиков и дол­ жен быть ответствен за оформление заказов на поставку; • диспетчер должен составлять расписание производства н основа­ нии заказов на сборку, полученных в результате работы "Плани­ ровать производство"; • диспетчер также должен получать копии заказов клиентов и отве­ чать за упаковку и комплектацию заказанных компьютеров, пере­ даваемых в работу "Отгрузка и получение". Задание состоит из пяти этапов. Выполняя каждый этап, Вы долж­ ны использовать приобретенные навыки. позиции. отображения новой информации. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: свойства модели: • Model Name: Предлагаемая модель компании Quill. • Time Frame: TO-BE • Рифозе: документировать предлагаемые изменения бизнес-про- цессов компании Quill. "Производство продукта". Расщепите эту работу в модель с тем же на­ званием. "Тестирование компьютеров" с диаграммы АО "Производство про­ диаграмме АО в "Сборку продукта". "Заказы на изготовление". кой и тестированием" в "Планирование производства". назовите ее "Дизайнер" и направьте как механизм к работе "Разрабо­ тать конфигурацию". выхода "Разработать конфигурацию" к границе диаграммы. Туннели- руйте эту стрелку (Resolve Border Arrow). Создайте ветвь этой стрел­ ки, идущую к управлению работы "Планирование производства" и на­ зовите ее "Список необходимых компонентов". ветвь стрелки "Стандарты на продукцию", идущую к управлению ра­ боты "Сборка продукта" и назовите ее "Правила сборки и тестирова­ ния". водства". щую к работе "Планирование производства". ную управляющую к работе "Планирование производства". Информация от поставщика Прогноз продаж Заказы клиентов Список необходимых компонентов Планирование производства Компоненты Заказы на изготов- "^ ление Заказ поставщику Правила сборки и тести­ рования Сборка продукта Планировщик производства Результаты сборки и тестирования Неисправные компоненты Собранные компьютеры Разработка конфигурации Стандарты |на продукцию Дизайнер Персонал производственного отдела Компоненты Инфор- Заказы Прогноз мация от клиен- продаж постав- тов Т Т Т г» с Производство продуктов Заказ поставщику Неисправные компоненты Собранные компьютеры Стандарты на продукцию выхода от работы "Планирование производства". "Собранные компьютеры" и свяжите ее на диаграмме АО с выходом работы "Сборка продукта". Сохраните модифицированную модель как OSsla.bpl, а модель верхнего уровня (Деятельность компании Quill) как OSslb.bpl. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: тельность компании Quill". Щелкните правой кнопкой мыши по рабо­ те. В контекстном меню выберите Merge Model. В появившемся диалоговом окне Continue with Merge? установите опцию Paste/Merge entire dictionaries, опцию Overwrite existing fields и щелкните по кнопке ОК. Модели должны слиться. "Информация от поставщика" и "Заказ поставщику". кетинг" на управление "Производство продукта". изводство продукта" на управление "Продажи и маркетинг". боты "Производство продукта". Звонки клиентов Правила и процедуры Продажи и маркетинг Компоненты от поставщика Заказы клиен­ тов Информация от поставщика f t Прогноз продаж Производство продукта Резуль­ таты сборки и тести­ рования Собранные компьютеры Неисправные компоненты Компоненты Маркетинпэвые материалы Бухгалтерская система *^ Стандарты на продукцию Возврат поставщику Отфузка и получение Проданные продукты Звонки клиентов Компоненты от поставщика Правила и процедуры Информация от поставщика Деятельность компании Quill Viewpoint Директор Purpose Моделировать текущие (AS-IS) бизнес-процессы компании Quill Маркетинговые материалы Заказ поставщику Возврат поставщику Проданные продукты Бухгалтерская система Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Model Explorer Существуют причины, по которым работа "Разработать конфигу­ рацию" должна быть на верхнем уровне, на диаграмме АО. Действи­ тельно, дизайнер разрабатывает стандарты на продукцию, включая правила сборки и тестирования и список необходимых для закупки компонентов. Тем самым дизайнер управляет производством продук­ та в целом, кроме того, управляет работой "Продажи и маркетинг". Было бы логично перенести эту работу на уровень выше. Используя возможности Model Explorer, перенесите работу "Раз­ на диаграмму АО. Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: Инфор­ мация от постав­ щика Прог­ ноз про­ даж ' ' Заказы клиен­ тов f Неисправные компоненты Стандарты на продукцию Список необходимых компонентов Планирование производства Заказы на изготовление Планировщик производства Правила сборки и тестирования Заказ Сборка продукта Персонал производственного отдела поставщику Результаты сборки и тестирования Неисправные компоненты Собранные компьютеры ю ON Разработать конфигурацию i$o Стандарты на продукцию Звонки клиентов Правила и процедуры Продажи и маркетинг Компоненты от поставщика Прогноз продаж Заказы Бухгалтерская система t t ? t Информация от поставщика Производство продукта Результаты сборки и тестирования Неисправные компоненты Собранные компьютеры Маркетинговые материалы Заказ поставщику Отгрузка и получение Возврат поставщику Проданные продукты Компоненты "Сборка продукта" Так же как в модели «as is», сборка продукта включает сборку компонентов и установку программного обеспечения. Однако теперь в работу "Сборка продукта" включена работа "Тестирование ком­ пьютера". Тестирование начинается после окончания процесса сборки ком­ пьютера и окончания процесса установки программного обеспечения. Если компьютер неисправен, в процессе тестирования у него заменя­ ют компоненты, информация о неисправных компонентах может быть направлена на работу "Подготовка компонентов". Такая инфор­ мация может помочь более тщательно подготавливать компоненты к сборке. Результатом процесса тестирования являются заказанные компьютеры и неисправные компоненты. Компоненты Подготовка компонентов Установка материнской платы и винчестера Установка I флоппи- ' ^ дисковода Л Результаты тестирования Установка дисковода CD-ROM Установка модема М О Н Инсталляция операционной системы дополнительного профаммного обеспечения Профаммное обеспечение Тестирование компьютеров Неисправные компьютеры Собранные компьютеры Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: "Продажа и маркетинг" Работа по продажам и маркетингу заключается в ответах на теле­ фонные звонки клиентов, предоставлении клиентам информации о ценах, оформлении заказов, внесении заказов в информационную сис­ тему и исследовании рынка. На основе этой информации декомпозируйте работу "Продажи и маркетинг" (IDEFO). Создайте следующие работы: • предоставление информации о ценах; • оформление заказов; • исследование рынка. Запрос информации о ценах Стандарты на продукцию Правила и процедуры Предоставление информации о ценах Заявки на заказ Оформление заказов Бухгалтерская система Результаты сборки и тестирования Заказы Исследование рынка Прогноз продаж Маркетинговые материалы Проверить правильност выполнения задани можно с использо­ ванием файлов, полученных из Интернета: При оформлении заказа важно проверить, существует ли такой клиент в нашей базе данных и, если не существует, внести его в БД и затем оформить заказ. Оформление заказа начинается со звонка кли­ ента. В процессе оформления заказа БД клиентов может просматри­ ваться и редактироваться. Заказ должен включать информацию о кли­ енте и информацию о заказанных продуктах. Оформление заказа подразумевает чтение и запись информации о прочих заказах. В процессе декомпозиции согласно правилам DFD мы преобразу­ ем граничные стрелки во внутренние, начинающиеся и заканчиваю­ щиеся на внешних ссылках. имена работ: • проверка и внесение клиента; • внесение заказа. ^ ^^ литре инструментов, внесите храни­ лища данных: • список продуктов; • список заказов. внешнюю ссылку: звонки клиентов. нии стрелок используйте словарь. "Заказы клиентов" двунаправленные. Для того чтобы сделать стрелку Activity Box Count OK ^ Сапс<й I Ц Ф Информация о клиентах Звонки клиентов Информация о клиентах, необходимая для оформления заказа Проверка и внесение клиента Заявки на заказ Стандарты на продукцию Внесение заказов Заказы клиентов двунаправленной, щелкните правой кнопкой по стрелке, выберите в контекстном меню пункт Style Editor и в диалоговом окне Style Editor выберите опцию Bidirectional. Tunnel) стрелки, подходящие и исходящие из работы "Оформление Стандарты на продукцию Заявки на заказ [' '] [' Правила и процедуры '] / Оформление заказов [' '] Бухг сист алтерс ема Заказы ^ клиентов 'кая Проверить правильность выполнения задания можно с использо­ ванием файлов, полученных из Интернета: на диаграмме DFD Некоторые стрелки с диаграммы IDEFO (не только с родитель­ ской) могут показываться на диаграмме DFD. Для отображения таких стрелок используется инструмент Off-Page Reference. щие работы: • разработка прогнозов продаж; • разработка маркетинговых материалов; • привлечение новых клиентов. нилища данных: • список клиентов; • список продуктов; • список заказов. • маркетинговые материалы; • прогноз продаж. Tunnel) стрелки, подходящие и исходящие из работы "Исследование рынка". з|Список заказов \ Заказы клиентов г прогнозов Прогноз продаж - b Проверка и внесение клиента р [Список продуктов \ i Стандарты на продукцию г Разработка маркетинговых u MapKeTHh материа/ - * Маркетинговые материалы |Список клиентов ' Информац Привлечение новых ИЯ u Проверка и внесение клиента , Информация о новом клиенте гг^ должна направляться к работе "Привлечение новых клиентов" диа­ вать инструмент Off-Page Reference. казов" создайте новую граничную стрелку, исходящую от работы "Проверка и внесение клиента", и назовите ее "Информация о новом в меню Off-Page Reference. В появившемся диалоговом окне Off-Page ^-*аде Arrow Referencf Diagraiir Display. Установите опцию Off-Page Reference label — Node number. правьте стрелку "Инфор- Информация О: О НОВОМ клиенте Привлечение новых клиентов . мация о новом клиенте на вход работы "Привле­ чение новых клиентов". Результат представлен на Проверить правильность выполнения задания мож­ но с использованием файлов, полученных из Интернета: на базе Erwin и BPWin Импорт модели данных из Erwin в BPWin. C:\BPCLASS/ тмтш ш\ •У^хУ ВЩН зультаты импорта и закройте диалоговое окно (Close). Attribute Dictionary и просмотрите ре­ зультаты импорта. на Model properties включите опцию Назначение ассоциаций сущностей и атрибутов: выберите пункт меню Arrow Date. со стрелкой. Сущности и их атрибуты Наименование стрелки Заявки на заказ Наименование сущности CUSTOMER LINE ITEM Наименование атрибута Customer City Customer Company Name Customer Fax Number Customer First Name Customer Last Name Customer Number Customer Phone Number Customer State | Customer Street Address Customer Zip Code Line Item Quantity | Line Item Sequence Number | Line Item Total | Product Code Sales Order Number Продолэюение Заявки на заказ i Наименование сущности SALES ORDER Наименование атрибута Customer Number Employee Id Payment Number | Sales Order Datetime | Sales Order Number Sales Order Shipment Charge | Sales Order Shipment Datetime | Sales Order Status | Sales Order Total | Shipment Method Code | Правой кнопкой мыши щелкните по стрелке "Заказы клиентов" и выберите пункт меню Arrow Date. Properties, ассоциируйте тот же самый набор сущностей и атрибутов вРмш Dale UsaaeEd^Of Назначение CRUD/IRUN ассоциаций: CRUD^RUN, которые необходимо ассоциировать со стрелкой "Заяв­ Типы атрибутов Product Code Customer Number Employee Id Sales Order Datetime Sales Order Number Sales Order Shipment Charge Sales Order Status Sales Order Total Shipment Method Code R R R R R R R R R R R R R R R R R R R R R R и и и и и и и и и и и и U и и и и и и и и и и R(IRUN) R R R R R R R R R R R R R R R R R R R R R R R и (IRUN) и и и и и и и и и и и и и и и и и и и и и и Создание новых объектов модели данных в BPWin: сущности "SALES FORECAST"H щелкните по Add. I«%. |SAi£S FOB£CASr PROBLEM PROSLEM ACTION PRODUCT PBODUCT SOLUTIOt-l AllfiMNst S^les Fen^cati Fredoc* Ouamsftfj» £^Шш ^ i^ki^mMs^m^, J Hi .; iiatj I F Ш^тазф мЗ иф^ j^lMt Ob$e m'- • Product Code; • Sales Forecast End Date; • Sales Forecast Product Quantity; • Sales Forecast Start Date. Erwin (ВРХ) и укажите имя файла экспорта (в папке C:\BPCLASS). (.Ьрх, в директории C:\BPCLASS). Execute. полнительную Subject Area "Оформление заказов" и щелкните по ции внутренних идентификаторов повторите процесс импорта из вжшввш Create S^ufion Valdat* Pfcdud IJlP^?>idNftid SFiwN ggfelfyp^' •в C^HfiEsel tp«£aiK CUSTOMER Customer Number Customer First Name Customer Last Name Customer Company Name Customer Street Address Customer City Customer State Customer Zip Code Customer Phone Number Customer Fax Number SALES FORECAST Sales Forecast Start Date Sales Forecast Product Quantity Sales Forecast End Date Product Code SALES ORDER Sales Order Number Sales Order Datetime Sales Order Shipment Charge Sales Order Total Sales Order Shipment Datetime Sales Order Status A LINE ITEM Line Item Sequence Number Line Item Quantity Line Item Total Erwin в BPWin. В результате им­ порта Вы должн получить сле­ Проверить правильность выпол­ нения задания можно с использо­ ванием файлов, полученных из Интернета: РЬЛТтиЫ BPvm\ /,J^' '^т-.Ш% щ^кШкотВШ к и печать диаграмм Перейдите в меню Report / DataUsage Report. Preview для просмотра отчета. Запустите Excel. В BPWin переключите Report Format на DDE и экспортируйте отчет в Excel. Перейдите в меню Report / Model Consistency Report. Щелкните по кнопке Preview и просмотрите отчет о синтаксических ошибках. Перейдите в меню File / Print, выберите диаграммы для печати и нажмите кнопку ОК. Г" Activity OtJtior»™ АттОрйвт Hn% Usage Optbrt*T ^"Цщкl^ Fotmet ! r|.flbded ^ ЩАХШт. r^iabOdbHect' ' ^ jpOnWIS DoWmeQ , ГдОЕТаЫ» • Г jBPTwir» Moto! TbodfdBror order. V Dfctiorwij Report Г Defirgoft SFlmerted ЗР* fietriejsjed lOFUfideted > MuKA/eiued Formal-^ I f H<«dbtP_^Mefge] P^ Bemofye^peciatDMr Qo» } Ущ^кт,: I grint., | fiepert... | Ijelp | ПРИЛОЖЕНИЯ Применение стандартов моделирования семейства IDEF для совершенствования Регламента Государственной Думы Российской Федерации вания IDEF к настоящему времени утвердилось де-факто как обще­ признанная универсальная методология описания систем. Использо­ вание этой методологии для решения задачи совершенствования Регламента Государственной Думы Российской Федерации может быть предопределено, с одной стороны, простотой и наглядностью результатов моделирования, с другой стороны, возможностью доста­ точно полного описания и анализа поведения объектов, обеспечиваю­ щих функционирование системы и взаимосвязей между ними. В качестве примера использования стандартов IDEF для модели­ Материалы для регистрации депутатских объединений Депутаты, не являющиеся членами депутатских групп Регламент ГДРФ Регистрация депутатских объединений ^ Временный секретариат ГДРФ Депутатские фракции Депутатские фуппы Комитет ГД РФ по регламенту и организации работы Материалы для регистрации депутатских объединений Депутаты, не явля­ f- ющиеся членами депутатских фупп ,—, Депутаты — члены Регистрация депутатских фракций i ^— депутатских фупп Временный секретариат ГДРФ \. i \ [с Регламент ГДРФ f Регистрация депутатских Фупп к < L Депутатские фракции Депутатские фуппы Прекращение членства в депутатских объединениях Депутаты — члены г^ Депутаты, не явля- ющиеся членами »—* к депутатских фупп Комитет ГД РФ по регламенту Руководителю фракции письменно уведомить об образовании фракции fop Получить сообщение выборов м Е л %. Депутатам ГД РФ составить заявления о вхождении во фракцию Е • Провести организационное собрание фракции 'Р- Руководителю депутатской группы письменно уведомить об образовании группы ор Депутатам ГД РФ составить заявления о вхождении в депутатскую группу Р- Провести организационное собрание депутатской группы Ор. Принятие решения депутатскопэ объединения о выводе депутата из его состава Ор Составление депутатом заявления о выходе из объединения, переходе в другое объединение, вхождении во вновь образованную группу —и |о • • Регистрация решения объединения или заявления депутата во Временном секретариате или комитете ГД по регламенту рода моделирования можно отнести наглядность получаемых моде­ чески упорядоченная совокупность диаграмм, аналогичных приве­ денным на рисунках) и возможность типизации объектов и связей между ними, что особенно важно для юридических систем, к каковым можно отнести Регламент Государственной Думы РФ, так как именно в юридических системах количество взаимодействующих объектов относительно велико по сравнению с системами других предметных областей. Другим важным моментом является существенное упрощение операции выявления и отображения взаимосвязей между объектами. В качестве иллюстрации верности этого утверждения приведем сле­ правами, определенными настоящим Регламентом". Однако раздел Регламента, озаглавленный "Права фракций и депутатских групп", от­ сутствует. Таким образом, даже задача простого перечисления уже су­ ществующих прав фракций превращается в задачу подробного изуче­ ния документа, состоящего из более сотни страниц. В то же время при наличии достаточно строго типизированной IDEF-модели Регламента и использовании соответствующих программных средств ответ на этот и подобные вопросы получается практически мгновенно. Еще одним положительным результатом применения IDEF-моде- лирования может стать выявление несогласованностеи в исследуемой системе. В нашем случае это наличие взаимоисключающих пунктов и статей в Регламенте. Необходимо упомянуть и о возможной научной новизне ожидае­ мых результатов, так как работ по IDEF-моделированию юридиче­ ских систем в России до настоящего времени не публиковалось. На основании изложенного считаем допустимым рекомендовать применение IDEF-моделирования в качестве одного из инструментов решения задачи совершенствования Регламента Государственной Ду­ мы Российской Федерации. в налогообложении Реализацию задачи построения моделей бизнес-процессов неко­ торой предметной области обязательно должно предварять де­ тальное обследование рассматриваемой области. Необходимо на словесном уровне описать проблему, которая долоюна быть решена методами структурного анализа'. В рыночных условиях налоги становятся практически основным инструментом государственного воздействия на экономику. В первую очередь они являются финансовым фундаментом государства, так как созданы прежде всего для финансрфования общественно необходи­ мых благ и услуг. Вместе с тем налоги все больше используются в ка­ честве инструмента регулирования и стимулирования. С их помощью государство оказывает влияние на темпы роста отдельных предпри­ ятий, отраслей и территорий. Проблема стабильности налоговых поступлений зависит прежде всего от используемого налогового инструментария, слаженности ра­ боты налоговой системы, а также от множества макроэкономических факторов. Налоги служат индикатором макроэкономических про­ блем, и поэтому их поступление в бюджетную систему зависит в основном от колебаний экономической конъюнктуры, финансовой политики государства, организационно-правовых проблем. В то же время среди определяющих причин неудовлетворительного поступ­ ления налоговых платежей в бюджетную систему страны необходимо вьщелить проблемы налогового механизма, нерациональную структу­ ру налоговой системы, недостаточно эффективную работу по плани­ рованию налоговых платежей. Ситуация со сбором налогов нестабильна, даже несмотря на уве­ личение числа принимаемых нормативных актов и проведенных ад­ министративных мероприятий. Анализ структуры и динамики нало­ говых поступлений показывает, что налоговая система России неэластична по отношению к быстро меняющейся экономической ^ Здесь и далее в этой главе курсивом вьщелено руководство по построению модели в рамках практического примера применения технологии моделирования. конъюнктуре. Так, например, собираемая в системе Министерства Российской Федерации по налогам и сбора налоговая информация не позволяет правильно оценить объем и структуру налоговых пла­ тежей. По всей видимости, в этих фактах кроется не отсутствие практиче­ ских навыков информационно-аналитической работы у сотрудников финансовых органов, а недостаточность собираемой информации, от- с)ггствие модели функционирования налоговой системы, продуман­ ной системы аналитической обработки данных. Разработка структурной функциональной модели деятельности инспекции МНС РФ позволит построить модель деятельности, пред­ ставляющей собой "снимок" технологии функционирования налого­ вой инспекции на момент обследования. Данная модель позволит про­ анализировать бизнес-процессы, происходящие на территориальном уровне с использованием методов системного анализа, и сформулиро­ вать, обобщить подходы по реинжинирингу налогового механизма. К рассматриваемым объектам моделирования относятся процес­ сы, осуществляемые на местном уровне налоговой службы, в целях контроля своевременности и полноты начисления и уплаты налого­ вых платежей юридическими и физическими лицами. После проведения детального обследования предметной области необходимо четко определить цель будущего проекта, достиэюение которой позволит создать инструмент для решения рассматривае­ мой проблемы. Перед началом реализации модели следует опреде­ лить методологию функционального моделирования, точку зрения, в соответствии с которыми будет разрабатываться модель. Модель моэюет быть построена как на бумаге, так и с помощью программ­ ного обеспечения, поддерэктвающего выбранную методологию моде­ лирования, или с помощью графических редакторов. Перед началом построения необходимо по результатам прове­ денного обследования предметной области определить перечень функций и список данных, которые будут использованы при реализа­ ции модели. Название проекта: Моделирование деятельности инспекции МНС РФ. Цель проеюга: Реализация структурной функциональной модели деятельности инспекции МНС РФ. Точка зрения: Руководство налоговой службы. Технология моделирования: метод функционального моделиро­ вания IDEFO. Список данных: методология; кадровый состав; техническое обеспечение; программное обеспечение; данные о налогоплательщиках; бухгалтерская, налоговая отчетность; платежные документы; входящие документы; отчетность; сведения по начислениям; сведения о состоянии лицевых счетов; выходящие документы; налоговые предписания. При формировании списка данных необходимо проводить группи­ ровку понятий в случае такой возмоэюности в целях повышения чи­ таемости диаграммы модели. Например, управлением рассматри­ ваемой модели могут слуэюить: законодательство, инструктивные материалы МНС РФ, долэюностные инструкции. Все эти понятия могут быть заменены термином "методология ". Примечания к мо­ дели могут содерэюать раскрытие каэюдого из понятий для лучшего понимания построенной модели. Уровень детализации и декомпозиции модели зависит от потреб­ ностей пользователя, который будет ею руководствоваться. По­ строение модели является итеративным процессом, т.е. первый реа­ лизованный вариант модели, скорее всего, не будет окончательным и будет дополняться в дальнейшем. Список функций: В модели фигурируют следующие функциональные блоки: Деятельность инспекции МНС РФ — АО Регистрация налогоплательщиков — АН Ведение лицевых карточек по подоходному налогу, налогу на рекламу, Создание и актуализация словаря необходимы для упрощения по­ нимания реализованной модели пользователем, для которого она предназначается. Кроме того, указанный словарь терминов позволя­ ет исключить возмоэюную неоднозначность трактования модели в дальнейшем. Бухгалтерская, налоговая отчетность — данные, предостав­ ляемые налогоплательщиком, на основании которых будет произво­ диться расчет налога. Входящие документы — данные, предоставляемые от внешнего источника и связанные с деятельностью налогового органа, например, сведения из банков о движении на счетах граждан сумм свыше Выходящие документы — данные, предоставляемые внешним источникам в результате деятельности налогового органа, например требования об уплате налога, ответы на запросы и т.д. Данные о налогоплательщиках — данные, предоставляемые внешними источниками, отражающие информацию о налогоплатель­ щике, например, документы, подтверждающие право на пользование льготой, расчетные счета налогоплательщика и т.д. Кадровый состав — сотрудники инспекции. Методология — совокупность приемов и методов налогообло­ жения. Отчетность — стандартная отчетность, предназначенна для передачи в вышестоящие структуры либо для внутреннег пользо­ вания. Платежные документы — данные о налоговых поступлениях. Программное обеспечение — совокупность программных при­ ложений для автоматизации деятельности сотрудников инспекции. Сведения о состоянии лицевых счетов — данные, предназна­ ченные для внутренней работы инспекции либо предоставляемые на­ логоплательщику. Сведения по начислениям — данные — результаты расчета на­ лога, необходимые для ведения лицевого счета налогоплательщика. Техническое обеспечение —совокупность аппаратных средств. Данные о плательщиках Бухгалтерская отчетность Входящие документы Платежные документы Методо­ логия Деятельность ИМНС РФ Кадровый состав Профам- мное обеспе­ чение Отчетность Выходящие документы Техни­ ческое обеспе­ чение Проводить дальнейшую декомпозицию не представляется целе­ сообразным с точки зрения руководства МНС РФ, так какрассмот- репный третий уровень и его декомпозиция предполагают уэюе рассмотрение с г.очки зрения методологов Управления МНС РФ по оперативно-бухгалтерскому учету. Бухгалтерская отчетность Платежные документы Входящие ДдкуМёйГЫ Данные о плательщиках Методология Деятельность отдела налого­ обложения ФЛ Деятельность отдела налого­ обложения ЮЛ Кадровый состав Деятельность отдела АХО Программно- аппаратное обеспечение Выходящие документы Отчетность Деятельность отдела инфор­ матизации т Профам- мное обеспе­ чение Техни­ ческое обеспе­ чение О Входящие документы Бухгалтерскря отчетность Платежные документы Работа сох сведениями взаимодействующих структур Данные о плательщиках f t Данные для расчетов Методология Налогообложение имущества • Начисления (и/н) Налогообложение по доходам граждан Контроль за финансовым состоянием Регистрация налогопла­ тельщиков Начисления (п/н) Кадровый состав Оперативно- бухгалтерский учет Данные лицевого счета Выходящие^ документы Отчеты по данным налогообложения Отчеты Программно- аппаратное обеспечение Платежные документы Начисления (п/н) Начисления (и/н) Ведение реестра платежных документов Поступления Ведение лицевых карточек по подоходному налогу ? t Методология Ведение реестра поступлений Ведение лицевых карточек по имущественным налогам Программно- аппаратное обеспечение Кадровый состав Ведение реестра заключений Формирование отчетных форм Ведение реестра требований J Выходящие документы Данные лицевого счета' Сведения о плательщиках Целесообразным является краткое описание задач, которые ре­ шаются на уровне каэюдого из функциональных блоков, и принципы его декомпозиции. Очевидно, что диаграммы первого и второго уровня могут быть объединены. Однако для лучшей читаемости модели следует отдель­ но рассматривать деятельность отдела юридических и физических лиц путем рассмотрения их на следующем уровне, А L Деятельность отдела налогообложения юридических лиц. На данном этапе рассматривается методология деятельности от­ дела налогообложения юридических лиц в целом. Декомпозиция про­ ведена в соответствии с организационно-штатной структурой отдела. На данном этапе рассматривается методология деятельности от­ дела налогообложения физических лиц в целом. Декомпозиция про­ ведена также в соответствии с организационно-штатной структурой отдела. В отделе учета и отчетности ведется учет произведенных налого­ плательщикам начислений, поступивших от них платежей, расчет сумм пени за несвоевременную уплату налогов (ведение лицевых кар­ точек налогоплательщиков) и т.д. Декомпозиция производится в соответствии с функциями, возло­ женными на отдел оперативно-бухгалтерского учета. Данные собираются и вводятся в информационную систему на ос­ новании выписки по банку, после чего данные поступлений, возвра­ тов разносятся в лицевые карточки. Разработанная модель содержит еще ряд достоинств, позволяю­ щих повысить эффективность работы налоговой службы: • анализ технологии работы на основе этой модели позволяет вы­ явить узкие места и увеличить производительность труда сотруд­ ников налоговых инспекций; • возможность быстрого и качественно иного обучения новых со­ трудников инспекции МНС РФ. пз Моделирование управленческого учета на предприятии В условиях конкуренции руководству предприятия требуется опе­ ративная информация для принятия решений. Финансовая отчетность предоставляет лишь часть необходимой информации в виде ограни­ ченного круга обобщенных стоимостных показателей. Бухгалтерский учет в первую очередь предназначен для предоставления информации для внешних пользователей. Этим обусловлено наличие нормативных требований к его ведению (документирование, стандартные методы и формы отчетности), которые делают данные бухгалтерского учета не пригодными для принятия решений. Функцию обеспечения руково­ дства предприятия необходимой информацией выполняет управлен­ ческий учет, который не регламентируется законодательно, а опреде­ ляется прежде всего целями предприятия. Институт дипломированных бухгалтеров в области управления (Charted Institute of Management Accountants) определяет управленче­ ский учет как деятельность по обеспечению руководства информаци­ ей, которая необходима ему для управления предприятием с макси­ мально возможной степенью эффективности. Информация, которую обеспечивает управленческий учет, может быть представлена в любой форме по выбору руководства. Большинство работ по управленческому учету российских авто­ ров и переводных работ иностранных авторов описывают отдельные элементы управленческого учета: методики учета и распределения за­ трат, учет по центрам ответственности, систему управленческой от­ четности и другие, но не дают целостного представления о бизнес- процессе, что затрудняет их использование для организации управ­ ленческого учета на предприятии. Восполнить этот пробел можно с помощью разработки модели данного процесса. Название проекта: Организация управленческого учета на пред­ приятии. Цель проекта: подготовит рабочую модел бизнес-процесса управленческого учета для внедрени на предприятии. Точка зрения: руководство предприятия. Инструментарий: методология функционального моделирова­ Список данных: потребность в управленческой информации; стратегия предприятия; управленческая информация; информационная система; финансовая функция; центры ответственности; руководство предприятия; данные; методология управленческого учета; финансовая отчетность; обработанные данные; стратегия управленческого учета; имеющиеся ресурсы; квалификация персонала; первичные документы; данные в информационной системе; подтвержденные данные; отчетность в разрезе центров ответственности; сводная отчетность; отчетность по требованию. ПЗ.З Список функций В модели использованы следующие функции: Организовать управленческий учет — АО Определить стратегию управленческого учета — АН Подготовить отчетность по требованию — АЗЗ Данные — факты, характеризующи деятельность предприятия, подлежащие количественному выражению. Данные в информационной системе —данные, введенные в ин­ формационную систему и разнесенные по аналитическим признакам. Имеющиеся ресурсы — персонал и информационная система в распоряжении предприятия. Информационная система — совокупность программных при­ ложений, баз данных, используемых для управления предприятием. Квалификация персонала — совокупность знаний, умений и на­ выков персонала в конкретной профессиональной области. Методология управленческого учета — совокупность приемов и методов ведения управленческого учета. Обработанные данные — данные, разнесенные по объектам уче­ та и центрам ответственности. Отчетность в разрезе центров ответственности — стандартная управленческая отчетность, составленная для каждого центра ответ­ ственности. Эта отчетность используется руководителями центров от­ ветственности для принятия решений в рамках их должностных пол­ номочий. Отчетность по требованию — управленческая отчетность не­ стандартной формы, используемая для пояснения стандартной отчет­ ности. Первичные документы — документы, подтверждающие факты совершения хозяйственных операций, оформленные в соответствии с действующим законодательством и нормативными актами. Подтвержденные данные — данные, соответствующие первич­ ным документам. Данные в информационной системе, обозначенные как соответствующие первичным документам. Потребность в управленческой информации — обоснованная необходимость получения управленческой информации. Руководство предприятия — должностные лица, несущие ко­ нечную ответственность за принимаемые ими управленческие реше­ ния в пределах своей компетенции. Сводная отчетность — стандартная управленческая отчетность, характеризующая деятельность предприятия в целом. Деятельность центров ответственности представлена обобщающими показателями. Стратегия предприятия — совокупность целевых ориентиров, определяющих деятельность предприятия в долгосрочном периоде. Стратегия управленческого учета — формализованные потреб­ ности руководства предприятия в управленческой информации. Управленческая информация — информация, необходимая для принятия управленческих решений. Управленческая отчетность — управленческая информация, представленная в удобной для прочтения форме. Может быть стан­ дартной, подготавливаемой регулярно в установленной форме, и не­ стандартной, подготавливаемой по требованию. Управленческий учет — деятельность по обеспечению руково­ дства предприятия информацией, необходимой для принятия управ­ ленческих решений. Финансовая отчетность — агрегированная отчетность, подго­ тавливаемая на регулярной основе для внешних пользователей ин­ формации. Требования к составу, порядку составления и срокам предоставления финансовой отчетности устанавливаются законода­ тельством или стандартами бухгалтерского учета. Финансовая функция — бухгалтерия и финансовые подразделе­ ния предприятия. Центры ответственности — структурные сегменты предпри­ ятия, руководители которых несут ответственность за конкретные по­ казатели деятельности (например, руководитель центра затрат отвеча­ ет за затраты своего сегмента, руководитель центра прибыли — за затраты и вьфучку и т.д.) На этом этапе разрабатывается методология управленческого уче­ та, которая является контролем для следующих этапов. От его органи­ зации во многом зависит успешность процесса управленческого учета в целом. АН. На первом этапе декомпозиции руководством определяется стратегия управленческого учета на основе потребностей в управлен­ ческой информации. Его задача формализовать потребности и увязать Потребности в управленческой информации Стратегия предприятия f Организовать управленческий учет Управленческая информация к к к к Руко- Центры Финан- Информа- водство ответ- совая ционная пред- ствен- функция система приятия ности Потребность в управленческой информации ^-ч Данные Руководство предприятия Стратегия предприятия Разработать методологию управленческого Методология управленческого учета Собрать и обработать данные Центры ответствен­ ности Обрабо­ танные данные Финансовая отчетность Подготовить управленческую отчетность Финансовая функция Управленческая информация Информа­ ционная система Обработанные данные _| Потребности в управленческой информации } Методология [ управленческого учета Г Подготовить отчетность по центрам ответ­ i Фи^ фy^ i г L Отчетность в разрезе центров ответ­ ственности ' ' ¥ Сделать сводную i ^ансова жция я i i I Финансовая отчетность Управленческая информация Сводная отчетность т Подготовить отчетность i i i Отчетность по требо­ ванию Информа­ ционная Рис. ПЗ.З. Одна из декомпозиций второго уровня стратегии управленческого учета, оценивается эффективность страте­ гии с точки зрения затрат имеющихся ресурсов и необходимость при­ влечения дополнительных ресурсов. приемы и методы ведения управленческого учета с учетом ресурсов, имеющихся в распоряжении предприятия. На этом этапе готовятся данные, составляющие основу управлен­ ческой информации. непосредственно центрами ответственности, что обеспечивает опера­ тивность поступления информации. Состав данных, аналитические признаки и сроки их учета определяются методологией. подтверждает данные в информационной системе. В случае расхож­ дений данные корректируются на основе первичных документов. Подтвержденные данные используются для составления финансовой отчетности. учета и центрам ответственности. При наличи достаточной аналити­ ки это осуществляется автоматически. На этом этапе формируется управленческая отчетность. При хоро­ шо разработанной методологии отчетность может формироваться ав­ томатически. Роль финансовой функции как механизма зависит от возможностей информационной системы. ности позволяет сформировать отчетность в разрезе центров ответст­ венности. Форма отчетов и сроки их предоставления определяются методологией. отчетности центров ответственности и других обработанных данных. В части подтвержденных данных контролем выступает финансовая отчетность. АЗЗ. Отчетность по требованию также основана на обработанных данных. Поскольку ее формы не предусмотрены методологией, они предварительно разрабатываются финансовой функцией. Моделирование процесса создания и организации реинвестиционной деятельности холдинговой компании в Республике Австрия Постановка задачи^ В течение последних лет налоговыми и финансовыми органами РФ был предпринят ряд мер, наьсладывающих существенные ограни­ связи особо следует упомянуть Положение ЦБ РФ "О порядке выда­ чи Банком России разрешений на проведение отдельных видов валютных операций, связанных с движением капитала", которое в обязательном порядке предусматривает получение разрешений на осуществление любых инвестиционных операций, связанных с осу­ ществлением взноса в уставный капитал любой зарубежной компа­ капитал финансовых и оффшорных компаний попадают под действие т.е. в любом случае). Это разрешение выдает Центральный банк Рос­ сийской Федерации, требующий в свою очередь представления спе­ циального разрешения Минэкономики, которое должно вынести суж­ дение о том, не противоречит ли инвестиционная сделка интересам российской экономики. Подобные ограничения особенно неудобны для российских ком­ паний, активно работающих на зарубежных рынках посредством ор­ ганизованных за границей дочерних компаний, а также для молодых перспективных компаний, планирующих выход на западный рынок. Эти компании часто сталкиваютдя с необходимостью осуществления инвестиционных операций за рубежом (к примеру, требуется увели­ чить уставный капитал дочерней компании). Несмотря на то, что по­ добные операции необходимы для поддержания нормальной жизне­ деятельности компании, их осуществление напрямую российской ' Материал этого приложения любезно предоставлен авторам книги А. Мнаца- кановым. компанией зачастую является невозможным без нарушения отечест­ венного законодательства. Возможным выходом из сложившейся ситуации является созда­ ние базисной холдинговой компании в одной из развитых западноев­ ропейских стран, имеющих репутацию "холдинговых центров", например в Австрии. Австрия упомянута в данном контексте не слу­ чайно, поскольку законодательство этой страны, а также Конвенция об избежании двойного налогообложения между Россией и Австрией предоставляют для базисных холдинговых компаний, принадлежа­ щих российским резидентам, уникальные возможности (например, дивиденды, получаемые холдингом от дочерних компаний, при опре­ деленных условиях освобождаются в Австрии от налогообложения). Создание подобного холдинга и организация его деятельности яв­ ляются для российской компании, как правило, непростой задачей. К сожалению, приходится констатировать, что в нашей стране на дан­ ный момент ощущается дефицит сотрудников, досконально знако­ мых с западноевропейским налоговым правом и западными деловыми обычаями. Недостаток подобного рода кадров даже в некоторых крупных российских компаниях нередко приводил к плачевным ре­ зультатам. По этой причине задача создания базисной холдинговой компании в последнее время все чаще перенимается специализиро­ ванными компаниями — резидентами Австрии. Специализирован­ ная компания сначала создает холдинг в Австрии, затем продает его российскому заказчику и впоследствии осуществляет от лица послед­ него доверительное управление холдингом (представители специа­ лизированной компании избираются в совет директоров холдинга). Доверительное управление длится до тех пор, пока не будет налаже­ на бесперебойная деятельность базисной холдинговой компании. Речь идет в первую очередь о выполнении трех основополагающих задач: • осуществить внесение в холдинг пакетов акций дочерних компа­ ний российского заказчика (создание первичной структуры хол­ динга); • осуществить покупку дополнительных пакетов акций дочерних компаний и (или) произвести повышение их уставного капитала; • наладить механизмы перевода средств дочерних компаний и их консолидации на счетах холдинга. После этого базисная холдинговая компания оказывается в со­ стоянии без серьезных осложнений осуществлять свою инвестицион- ную и реинвестиционну деятельность. В этот момен задачу специа­ лизированной компании можно считать выполненной. Поскольку в данном случае речь идет о сверхсложном и достаточ­ но продолжительном процессе, представляется целесообразным ре­ шать возникающие при его осуществлении проблемы при помощи создания модели IDEFO. при помощи технологии IDEFO Точка зрения. Возможные точки зрения: • менеджмент российской компании-заказчика; • менеджмент специализированной компании — резидента Авст­ рии. Представляется целесообразным в качестве точки зрения принять позицию специализированной австрийской компании, поскольку именно она отвечает за успешное выполнение поставленных задач и осуществляет непосредственный контроль над рассматриваемым про­ цессом. рассматриваемой проблемы Основная задача, стоящая перед менеджером, как это следует ис­ ходя из специфики рассматриваемой проблемы, заключается в реин­ вестировании денежных средств клиента через созданную холдинго­ вую компанию в Австрии. Он получает от клиента: • информацию (о самой компании-клиенте и ее дочерних ком­ паниях); • денежные средства и пакеты акций дочерних компаний, которые будут вноситься в холдинг. Информация и средства, получаемые от клиента, вместе со средст­ вами, самостоятельно инвестируемыми специализированной компа­ нией, представляют собой вход. Единственным желательным с точки зрения выполнения поставленной задачи выходом являются средства, реинвестируемые холдинговой компанией. Это обстоятельство осо­ бенно важно принимать во внимание, если учесть, что при реализации рассматриваемого процесса будет возможен лишь один выход, по­ скольку неудача на одном из функциональных этапов выполнения поставленной задачи, имеющая результатом выходящие данны типа "отказ в ...", автоматически предполагает невозможность достижения менеджментом специализированной компании целей, стоящих в рамках выполнения поставленной задачи. Напротив, получение на выходе желаемых данных возможно лишь при достижении поло­ жительных результатов в рамках "критических" функциональных блоков. Это означает, что в рамках рассматриваемого процесса каж­ дый отдельный вариант выхода исключает все остальные варианты. Соответственно реализация процесса может иметь либо сугубо по­ ложительный, либо сугубо отрицательный результат. По этой при­ чине возможности для реинжиниринга процесса в данном случае являются достаточно ограниченными. Следовательно, для менедж­ мента специализированной компании целесообразно сконцентри­ роваться в первую очередь на выявлении источников экзистен- циональных рисков. Цели. Исходя из вышесказанного можно выявить основные цели, стоящие при моделировании рассматриваемого процесса. Помимо множества "микроцелей", можно выделить также не­ сколько основных целей, преследуемых ее составителем: Определить четкую последовательность действий, осуществле­ ние которых необходимо для достижения поставленных задач с целью точного определения величины и характера возможных временных и финансовых затрат. Из общего числа функциональных блоков большинство интересу­ ют нас лишь с точки зрения возможных, связанных с ними затрат. Особый же интерес представляют так называемые "критические функциональные блоки". Последние, в отличие от большинства ос­ тальных функциональных блоков, характеризуются тем, что неудача при выполнении поставленных в их рамках задач может быстро при­ вести к срыву всего проекта. В рамках рассматриваемой модели кри­ тическими являются те функциональные блоки, выходным результа­ том которых могут быть отказ в регистрации, открытии счета или отказ в предоставлении налоговых льгот. необходимо в рамках осуществления проекта. Это достаточно важный аспект, поскольку, с одной стороны, каж­ дая экспертиза стоит немалых денег, а с другой — отказ от своевре- менного проведения экспертизы может привести к негативным ре­ зультатам в ближайше критическо функционально блоке. Анализ отдельных функций. Поставленная задача будет решать­ ся путем построения функциональной модели процесса, представляю­ щей собой иерархию функций, связанных материалами и информаци­ онными потоками согласно правилам построения IDEFO-модели. Рассматриваемый процесс можно разбить на два основных функ­ циональных блока: зовать ее структуру. Каждый блок содержит в себе определенное число (системных) функций, большинство которых, в свою очередь, имеют сложную структуру. Далее предлагается анализ отдельных системных функций с уче­ том стоящих в рамках решения поставленной проблемы задач. Выполнение данной функции лишь маргинально различается в рамках выполнения различных задач, поэтому в нашем случае она не рассматривается подробнее. В рамках рассматриваемой системной функции присутствуют це­ ных рисков — "зарегистрировать компанию" и "открыть банковский счет". При этом риск отказа в регистрации компании следует оцени­ вать как значительно более высокий. По этой причине подача регист­ рационных документов должна предваряться экспертизой некоторых из них в торговой палате. казчику. В рамках данной системной функции присутствует лишь один "критический" блок — "зарегистрировать нового владельца компа­ нии". Тем не менее риск негативного выхода в данном случае является достаточно низким, расходы на проведение дополнительной экспер­ тизы представляются в данном случае неоправданными. "Критические" блоки отсутствуют. Тем не менее на данном этапе необходимо проведение правовой экспертизы с учетом трудностей, которые могут возникнуть в ходе процесса организации реинвестици- онной деятельности компани (основной риск, величину которого следует оценить, — риск отказа в предоставлении налоговых льгот). Стратегические решения должны приниматься именно на этом этапе, поскольку выход из процесса в позднейшие промежутки времени бу­ дет связан с дополнительными необоснованными затратами. компаний. "Критический" блок — "зарегистрировать увеличение уставного капитала компании". Риск негативного выхода невысок. "Критический" блок — всего один ("подать заявку на предостав­ ление налоговых льгот"), зато связанный, пожалуй, с наиболее суще­ ственным экзистенциональным риском. Неудача на данном этапе при­ водит не только к негативному результату в рамках выполнения поставленной задачи, но и к максимально высоким финансовым поте­ рям. Правовая экспертиза проводится ранее. Варианты реинжиниринга. В том случае, если разработанная модель на практике доказывает свою неэффективность, возникает по­ требность в ее "перестройке" (реинжиниринге). Причины неэффек­ тивности модели могут быть внешними и внутренними. К внутренним причинам относятся преимущественно ошибки, допущенные при со­ ставлении модели, к внешним — изменения параметров внешней сре­ ды, которые не были (и, возможно, не могли быть) учтены при состав­ лении модели. В качестве примера рассмотрим следующую ситуацию (в рамках вышеописанной модели; причем в ходе дальнейших анализов будем исходить из того, что ошибок при построении модели допущено не было, и, следовательно, все "помехи" будут иметь исключительно внешний характер): допустим, акционер холдинговой компании (ком­ пания-заказчик) отказывается предоставить ряд документов, необхо­ димых для получения холдингом налоговых льгот (см. декомпозицию пании"). Отказ происходит уже после того, как первая поставленная задача — увеличение уставного капитала дочерней оффшорной ком­ пании уже является выполненной. Выполнение же основной задачи — реинвестирования денежных средств клиейта через созданную хол­ динговую компанию в Австрии, в рамках разработанной модели явля­ ется в сложившейся ситуации невозможным. То, что соответствую­ щий риск не был учтен при построении исходной модели, нельзя считать ошибкой ее составителе — согласи клиента (российской компании) с условиями сделк (в число которых входил и предостав­ ление соответствующей документации) явилось одной из базовых предпосылок, исходя из которых конструировалась модель. В прин­ ципе специализированная компания в сложившейся ситуации имела бы право расторгнуть контракт с компанией-заказчиком, но мы будем исходить из того, что речь идет о "стратегическом" клиенте, которого специализированная компания ни в коем случае не захочет утратить и по этой причине предпочтет "перестройку" модели расторжению кон­ тракта. Далее приводятся два возможных варианта реинжиниринга процесса (общая задача предполагается неизменной). Поскольку компания-заказчик отказывается предоставлять в Ми­ нистерство финансов Австрии необходимые документы, министерст­ во отказывает холдинговой компании в предоставлении налоговых льгот. Следовательно, средства, перечисленные дочерней компанией в виде дивидендов, будут облагаться налогом (по ставке, близкой к стандартной). Следовательно, возникает необходимость поиска иных каналов перевода денежных средств. Возможным вариантом решения проблемы была бы организация дочерней компанией выдачи холдин­ гу так называемого "доверительного" кредита. Схема будет выглядеть следующим образом: банк, связанный тес­ ными и доверительными отношениями либо с компанией-заказчиком, либо со специализированной компанией, выдает холдингу кредит под залог денежных средств, перечисляемых дочерней компанией на свой счет в банке. После того как холдинг не выплачивает кредит обратно, банк просто забирает средства со счета дочерней компании, т.е. фак­ тически речь идет о перечислении денег (дивидендов) дочерней ком­ панией холдингу, которое со стороны, тем не менее, выглядит как кредит, вьщанный холдингу банком. Перечисленные средства, разу­ меется, налогами облагаться не будут. Произошедшие изменения за­ трагивают исключительно функцию "консолидировать средства на компании, возможен вариант ее поглощения холдингом. В дальней­ шем бывшая дочерняя компания будет считаться постоянным пред­ ставительством холдинговой компании в Лихтенштейне и пользо­ ваться существенными налоговыми льготами (между Лихтенштейном и Австрией существует конвенция об избежании двойного налогооб- ложения). В результате возникнет лишь необходимост интегриро­ вать в модел новую функци "осуществить поглощение дочерней компании холдингом" (что не будет связано с существенными слож­ ностями), а функция "консолидировать финансовые потоки холдинго­ вой компании настолько упростится, что потребность в ее декомпози­ ции исчезнет (поглощение может производиться сразу при внесении пакета акций дочерней компании в холдинговую или на дальнейших этапах); по этой причине может быть составлено несколько альтерна­ тивных вариантов соответствующей модели. Основные понятия, использованные в модели Законодательство Республики Австрия: положение "О государственных налогах и сборах" (ВАО); Закон "О налоге на прибыль предприятий и организаций" (kestg); Закон "О налоге на доходы физических лиц" (estg); Закон "О реорганизации предприятий" (umgrstg); Торговый кодекс Республики Австрия (НОВ); Закон "Об инвестиционных фондах" (invfg); Закон "Об обществах с ограниченной ответственностью" (gmbhg); Закон "Об акционерных обществах" (aktg); Закон "О рынке ценных бумаг" (KMG); Закон "О торговом регистре" (FBG). Законодательство Княжества Лихтенштейн: Кодекс торгового и гражданского права (PGR); Закон "О государственном надзоре за деятельностью предприятий и организаций с особым налоговым статусом"; Закон "Об акционерных обществах" (aktg); Закон "О банках и банковской деятельности" (BWG). Информация о компании-заказчике: учредительные документы; баланс. Помимо указанной информации, желательна информация о физи­ ческих лицах, с юридической точки зрения прямо или косвенно яв­ ляющихся собственниками компании-заказчика (они должны быть нерезидентами Австрии). Информация о существующих заграничных дочерних компаниях заказчика включает в себя следующие сведения о дочерних ком­ паниях: • о количестве; • о правовом статусе; • о характере осуществляемой деятельности; • о продолжительности существования; • о финансовом положении. Специализированная (консалтинговая) компания — компания, специализирующаяся на организации базисных холдинговых компа­ ний в Австрии. Компания-заказчик — российская компания, для которой специа­ лизированная компания создает базисную холдинговую компанию в Австрии и от лица которой осуществляет управление последней. Заграничная дочерняя компания компании-заказчика — загранич­ ная компания, в которой компания-заказчик владеет участием или па­ Учредительный договор (базисной холдинговой компании) — один из основных учредительных документов — подписывается фи­ зическими и/или юридическими лицами с целью создания ООО, со­ держит в себе положения, регулирующие дальнейшую деятельность компании. Экспертиза торговой палаты — законодательно предписанная проверка торговой палатой отдельных положений учредительного до­ говора на предмет их соответствия национальному законодательству. Правовая экспертиза (специализированной компании) — правовая экспертиза проводимых холдингом операций, осуществляемая экс­ пертами специализированной компании. Справка банка, подтверэюдающая зачисление средству — пись­ менное уведомление банка, подтверждающее поступление средств на указанный счет. Протокол учредительного собрания (акционерного собрания) — документ, в котором в письменном виде фиксируются решения, при­ нимаемые учредительным (акционерным) собранием. В ходе решения поставленной задачи планируется дважды прове­ дение учредительного собрания базисной холдинговой компании, ко­ торая должна существовать в форме GmbH (общество с ограниченной ответственностью), и проведение акционерного собрания дочерней компании в Лихтенштейне. Учредительные собрания холдинга долж­ ны принять решения соответственно об утверждении совета директо­ ров и покупке дополнительного пакета акций дочерней компании в Лихтенштейне. Акционерное собрание дочерней компании должно принять решение о выплате дивидендов материнской компании. Все решения должны быть зафиксированы в соответствующем протоколе. Концепция консолидации финансовых активов — зафиксирован­ ная в письменном виде концепция, призванная определить более под­ робную структуру финансовых потоков холдинга. Принимается после решения ряда важных организационно-правовых вопросов (т.е. уже после того, как завершается формирование первичной организацион­ ной структуры компании). Реинвестируемые средства (холдинга) — финансовые средства холдинга, за счет которых осуществляется приобретение активов (ма­ териальных и нематериальных), поступающих в фактическое распо­ ряжение компании-заказчика (как владельца базисной холдинговой компании). о Информация о дочерней компании заказчика Информация о заказчике Пакет акций дочерней компании Платежные средства консалтинговой компании Платежные средства заказчика V Инст­ рукции заказ­ чика Законо­ датель­ ство Рес­ публики Австрия Законода­ тельство Княжества Лихтен­ штейн Отказ в регистрации сделки купли-продажи компании Отказ в регистрации компании Отказ L B открытии счета Свидетельство о регистрации компании Создать холдинговую компанию в Австрии и организовать ее реинвестиционную деятельность Минис­ терство финан­ сов Рес­ публики Австрия Банки Торго­ вая палата Менедж­ мент компа­ нии и за­ казчика Акцио­ неры дочер­ ней ком­ пании Реинвести­ руемые средства Минис­ терство финансов Княжества Лихтен­ штейн Отказ в предо­ ставлении налоговых льгот Отказ в регистрации уставного капитала компании Пакет акций дочерней компании Информация о дочерней компании Платежные средства консалтинговой компании заказчика Информация о заказчике Платежные средства заказчика V Инст­ рукции заказ­ чика Законодательство Республики Австрия Создать холдинговую компанию в Австрии Отказ в открытии счета Учредительный договор Свидетельство о реги­ страции внесения па­ кета акций дочерней компании Минис­ терство финан­ сов Рес­ публики Австрия Банк Торго­ вая палата Свидетельство о реги­ страции сделки купли- продажи компании V f f f Законодательство Княжества Лихтенштейн Отказ в реги- Свидетельство страции сделки о регистрации купли-продажи компании компании iL Отказ в регистрации компании Отказ в регистрации увеличения уставного капитала компании Организовать реинвестиционную деятельность компании Менедж­ мент компа­ нии и за­ казчика Акцио­ неры дочер­ ней ком­ пании Отказ в предостав­ лении нало­ говых льгот Минис­ терство финансов Княжества Лихтен­ штейн Реинвести­ руемые средства Информация о заказчике Информация о дочерней компании заказчика Инструкции заказчика Разработать концепцию создания компании Р^ Платежные средства консалтинговой компании Законодательство Республики Австрия Создать компанию Платежные средства заказчика Пакет акций дочерней компании Торговая палата Свидетель­ ство об отк­ рытии счета V Отказ в ре­ гистрации компании Отказ в открытии счета Продать компанию заказчику Банк Менеджмент компании- заказчика Платежные средства холдинга V Свидетельство о регистрации компании Учреди­ тельный договор Отказ в регист­ рации сделки купли- продажи компании Внести пакет акций дочерней компании Свидетельство о решстрации сделки купли- продажи компании Свидетельство о регистрации внесения пакета акций дочерней компании Министерство финансов Республики Австрия Концепция создания компании Разработать I и подписать ' ^ учредительный договор Платежные средства консалтинговой компании Возвращение на доработку Законодательство Республики Австрия Внести уставный капитал Платежные средства холдинга ^Провести Y*^ экспертизу учредительных документов Документы, подтверждающие перечисление средств Банки V Положительное заключение торговой палаты Свидетельство о регистрации компании М Зарегист­ рировать компанию Торговая палата Учредительный договор Отказ в регистрации компании Открыть банковский счет Отказа открытии счета Свидетельство об открытии счета Министерство финансов Республики Австрия Свидетельство о регистрации компании Р^ Свидетельство об открытии счета Платежные средства заказчика Концепция создания компании Заключить договор купли-продажи компании Договор купли- продажи компании V Инструкции заказчика Провести расчеты с заказчиком Менеджмент компании-заказчика У Законодательство Республики Австрия Платежные средства холдинга Зарегистрировать нового владельца компании Банк Министерство финансов Республики Австрия Отказ в регист­ рации сделки купли- продажи компании Свидетельство о регистрации сделки купли- продажи компании Свидетельство о регистрации сделки купли- продажи компании Z Учредительный договор £ Провести учредительное собрание ^ Информация о дочерней кйМПдИИИ заказчика Инструкции заказчика Р" Разработать концепцию оптимизации структуры Состав совета директоров Положительный результат экспертизы Провести экспертизу Возвращение на доработку Пакет акций дочерней компании Платежные средства холдинга Законодательство Республики Австрия Концепция оптимизации структуры компании Внести пакет акций Справка об уплате налогов и сборов Провести расчеты с Минфином Документы, подтверждающие внесение акций Менеджмент компании-заказчика Свидетельство о регистрации внесения пакета акций дочерней компании Зарегистриро- "^ вать внесение пакета акций ^ Банк Министерство финансов Республики Австрия ON Учредительный договор Платежные средства заказчика V Свидетельство о реги­ страции сделки купли- продажи компании— Законодательство Республики Австрия Инструкции заказчика Свидетельство о регист- рации внесения пакета Информация о заказчике Приобрести дополнительный пакет акций дочерней компании Минис­ терство финансов Княжества Лихтен­ штейн Акцио­ неры дочер­ ней ком­ пании Банк К Минис­ терство финан­ сов Рес­ публики Австрия Законодательство Княжества Лихтенштейн Отказ в регистрации увеличения уставного капитала компании Консолидировать средства на счетах компании Отказ в предоставлении налоговых льгот Реинвестируемые средства Менеджмент компании- заказчика Свидетельство о регистрации сделки купли- продажи компании А ^ Учредительный договор Законодательство Республики Австрия ТУТ Провести учредительное |->^ собрание i Решение об увеличении уставного капитала Свидетельство о регистрации внесения пакета акций дочерней компании Платежные средства заказчика Инструкции заказчика Зарегистрировать увеличение уставного капи­ тала компании Менеджмент компании- заказчика Законодательство Княжества Лихтенштейн "Заключить договор купли-продажи дополнительного пакета акций до­ черней компании Регистрационное свидетельство Министерство финансов Республики Австрия Договор купли- продажи V Документы, подтверж­ дающие перечисле­ ние средств Провести расчеты с продавцом ^ У Р^ Отказ в реги­ страции уве­ личения уставного капитала компании Свидетельство о регистрации сделки по при­ обретению до­ полнительного пакета акций дочерней компании Зарегистриро­ вать сделку Акционеры дочерней компании Министерство финансов Княжества Лихтенштейн ;^ Свидетельство сделки по приобре­ тению дополнитель­ ного пакета акций дочерней компании Z v_ Законодательство Республики Австрия Подать заявку о предоставле­ нии налоговых льгот Информация о заказчике Законодательство Княжества Лихтенштейн Провести акционерное собрание дочер­ ней компании Свидетельство об отказе в предоставлении налоговых льгот Министерство финансов Республики Австрия Отказ в предоставлении налоговых льгот Гарантия дочерней компании Платежные средства Провести расчеты между дочерней ком­ панией и банком Платежные средства (кредит) [^Заключить кре- дитный договор с банком от лица холдинговой компании А Акционеры дочерней компании Платежные средства дочерней компании Банк Инструкции заказчика Реинвести­ руемые средства ^ Консолидиро­ вать финансо­ вые активы на счетах компании Менеджмент компании- заказчика ГЛОССАРИЙ IDEFO — стандарт моделирования, поддерживающий графиче­ ское описание бизнес-функций как набора взаимозависимых действий и информации о ресурсах, необходимых для каждого действия. На­ значение модели IDEFO состоит в документировании и пересмотре на­ значения и состава функций для повышения эффективности функцио­ нирования организации. вающий графическое описание непосредственного механизма функ­ разработки двух видов сетевых диаграмм: • потоков для бизнес-процессов; • изменения состояния объекта. DFD — технология моделирования, показывающая, как объекты (включая и данные) реально перемещаются от одного действия к другому. Бизнес-процесс (Business-process) — термин, используемый для описания того, как в процессе функционирования организации вы­ моделирования бизнес-процессов посредством применения нотации, ориентированной на идее задания последовательности выполнения действий и определении времени их выполнения. Бизнес-функция (Business-function) — термин, используемый для описания того, что в процессе функционирования организации выполняют те или иные действия. IDEFO обеспечивает поддержку моделирования бизнес-функций посредством нотации, использую­ щей действия и стрелки. Вход (Input arrow) — стрелка, входящая в левую часть блока диа­ мые действием, обозначенной данным блоком, и которые необходи­ мы для получения выхода. Выход (Output arrow) — стрелка, выходящая из правой стороны блока диаграммы IDEFO. Выход обозначает изделия или информа­ цию, полученные в результате выполнения действия, обозначенного блоком. Границы моделирования (Scope) — ширина охват и глубина детализации пр описани моделируемого набора объектов. Действие (Activity) — описание набора мероприятий, имеющего целью обработку или передачу данных или ресурсов (например, "Обработать заказ" или "Провести технический контроль"). Модели IDEFO выделяют неэффективные действия (у которых отсутствует управление или выход) и, таким образом, способствуют работе по проведению реинжиниринга бизнес-процессов. Действие в модели мероприятие, принятие решения или другую процедуру, выполняе­ мую системой или организацией. Действия в диаграммах DFZ) отобра­ жают обработку или передачу данных. Механизм исполнения (Mechanism arrow) — стрелка, входящая в блок диаграммы IDEFO снизу и обозначающая персонал, оборудова­ ние и другие, не потребляемые в процессе функционирования ресур­ сы, используемые для выполнения действия, обозначаемого блоком. Стрелка (Arrow) — стрелка на диаграмме IDEFO представляет вход, управление, выход или механизм выполнения действия. На диа­ (стрелки, нарисованные сплошной линией), отношения (стрелки, нарисованные прерывистой линией) или поток (двухконечные стрел­ ки, нарисованные сплошной линией). В DFD стрелка обозначает поток данных между действиями, хранилищами данных и внешними ссылками. Управление (Control arrow) — ограничение для блока диаграм­ мы IDEFO, определяющее как, когда и при каких условиях выполня­ ется действие, обозначенное этим блоком. Это правила, стандарты, законы, должностные инструкции и т.п. Стрелки, обозначающие управление, входят в блоки диаграммы IDEFO сверху. РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА средства проектирования информационных систем. - М: Финансы и Книга представляет собой введение в проектирование ин­ формационных систем с помощью современных методов и средств. Содержит сведения по методологиям проектирования, структур­ ному и объектно-ориентированному подходам, характеристикам CASE-средств. Представлена концептуальная основа преподавания курса по ис­ пользованию CASE-технологий для проектирования и разработки информационных систем в системе повышения квалификации Ураль­ ского государственного технического университета ния при разработке банковских систем. - DiasoftNFO // Банковские В статье излагается опыт, накопленный компанией "Диасофт" в области структурного системного анализа банковской сферы. Показано, что методологии функционального моделирования, ле­ жащие в основе системного структурного анализа, позволАют до­ биться значительного повышения конкурентоспособности програм­ много обеспечения, снижают производственные издержки и время разработки. Изложены методологические основы области CASE-технологий. Содержит описание основных методов структурного анализа и про­ ектирования программного обеспечения систем обработки информа­ ции. Акцент на последовательное рассмотрение наиболее важных ас­ пектов системного структурного анализа делает эту книгу особенно полезной для аналитиков предметных областей, руководителей про­ граммных проектов, системны аналитиков, проектировщиков и раз­ работчиков информационных систем и систем реального времени. Обобщение опыта разработки консалтинговых проектов, выпол­ ненных для банков, промышленных и торговых предприятий, офис­ ных учреждений и т.д. Подробно рассматривается методологическая и инструментальная база выполнения консалтинговых проектов (CASE-технологии), анализируются подходы к реорганизации дея­ тельности предприятий; предлагается методология выполнения кон­ салтинговых проектов, апробированная на крупнейших российских предприятиях. Полезна как учебное пособие для "продвинутых" слу­ шателей. Весьма удачное с точки зрения подачи материала пособие для "непродвинутых" слушателей, в котором представлены фрагменты истории структурного подхода, а также основные моменты (с приме­ рами) технологий SADT и IDEF. Пособие по курсовому проектированию для слушателей военных учреждений, включающее все необходимое для исполнения проекта: требования к проекту, общие положения по CASE-моделированию, методика построения модели, методические примеры, а также описа­ ние основных функций поддерживающего технологию моделирова­ ния программного продукта BPWin. Практическое руководство по созданию информационных сис­ тем с помощью CASE-средств фирмы Platinum BPWin и ERWin. Из­ ложена методология создания модели процессов в BPWin и модели данных с помощью ERWin. Связывание модели процессов и модели данных. Создание объектной модели и ее связывание с моделью дан­ ных при помощи ERWin Translation Wizard. Создание качественных отчетов с помощью RPTWin. Очень хорошее, к тому же и современ- ное учебно пособи в обсуждаемой области, к сожалению, малопри­ годное для "непродвинутой" аудитории. Классический труд, в котором изложены основные концепции методологии SADT-IDEF (Structured Analysis and Design Technique). Подробно описан процесс построения функциональных моделей про­ цессов. Множество примеров, взятых из реальных аналитических проектов, иллюстрируют различные способы применения SADT в широком спектре областей. Представляет большую ценность как учебно-методическое пособие для начинающих изучать предмет, не потерявшее своей ценности за прошедшее с момента выхода время. учета и отчетности физических лиц территориальной налоговой ин­ спекции. Новые информационные технологии в финансово-кредит­ Пример использования IDEF-моделирования для автоматизации одной из задач налогообложения для физических лиц. учета и отчетности юридических лиц территориальной налоговой ин­ спекции. Новые информационные технологии в финансово-кредит­ Пример использования IDEF-моделирования для автоматизации одной из задач налогообложения юридических лиц. Теория и практика для выполнения лабораторных работ. Изложена технология современного структурного анализа биз­ нес-процессов на основе пакета международных стандартов модели­ рования IDEF. Благодаря доступной, хорошо структурированной форме подачи материала, а также тщательно подобранным примерам специалисты, прежде всего в области менеджмента, имеют возмож­ ность использовать рассмотренную в книге технологию в качестве рабочего инструмента в своей практической деятельности. ринг бизнес-процессов. Вводный курс. - М.: Финансовая академия, Конспект лекций. Приведены толковый словаоь терминов и подробный список литературы. Хорошее пособие для изучения подходов семейства IDEF и их от­ ражения в программе BPwin. Интернет-источники Сайт группы разработчиков IDEF, содержит множество материа­ лов по стандартам IDEF и их практическому применению. Имеет ссылки на форумы пользователей IDEF со всего мира. Сайт одной из ведущих компаний по реинжинирингу корпора­ ций, расположенной в Великобритании. Есть несколько статей по практическому применению IDEF в реинжиниринге. Сайт основного дистрибьютера компании Computer Associates в России. Оглавление IDEFO много пакета компьютерной поддержки технологии мо­ для совершенствования Регламента Государственной Приложения вестиционной деятельности холдинговой компании в Производственное издание Черемных Станислав Владимирович Семенов Илья Олегович Ручкин Владимир Сергеевич МОДЕЛИРОВАНИЕ И АНАЛИЗ СИСТЕМ. IDEF-ТЕХНОЛОГИИ: ПРАКТИКУМ Заведующая редакцией Л.А. Табакова Редактор Л.Д Григорьева Младший редактор НА. Федорова Художественный редактор Ю.И. Лртюхов Технический редактор Т.С. Маринина Корректоры Г. В. Хлопцева, Н.П. Сперанская Обложка художника О.В. Толмачева Издательство «Финансы и статистика» E-mail: mail@rinstat.ru http://www.finstat.ru E-mail: zakaz@veltip.ru


Внимание! Не забудьте ознакомиться с остальными документами данного пользователя!

Соседние файлы в текущем каталоге:

На сайте уже 21970 файлов общим размером 9.9 ГБ.

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

Не нашли нужный документ? Воспользуйтесь поиском по содержимому всех файлов сайта:



Каждый день, проснувшись по утру, заходи на obmendoc.ru

Товарищ, не ленись - делись файлами и новому учись!

Яндекс.Метрика