Методика написания дипломной работы по маркетингу (стр. 5 из 17)

· верхняя сторона имеет значение “Управление” (Control);

· левая сторона имеет значение “Вход” (Input);

· правая сторона имеет значение “Выход” (Output);

· нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер (АО).

Рис.3. Функциональный блок

Второе понятие интерфейсная дуга (Arrow). Также интерфейсные дуги называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

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

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

Третьим понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А0”. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую мы разрабатывали бы для того же самого предприятия, но уже с целью оптимизации логистических цепочек.

Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, и исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему, каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box. В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит, родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рис. 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм. Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

Рис. 4. Принципиальная схема декомпозиции функциональных блоков

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

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

Рассмотрим несколько примеров использования методов системного анализа.

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

Рис.5. Схема управления в конфликтной ситуации

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

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

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