Автоматизированная система учета затрат и ценообразования на производственном предприятии

Постановка задачи Вариант № 11.

Необходимо разработать курсовой проект на тему: «Автоматизированная система учета затрат и ценообразования на производственном предприятии».

Произвести сбор необходимой литературы и анализ входной информации.

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

Разработать эскизный проект будущей ИС.

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

Реализовать эскизный проект с помощью инструментов моделирования BPwin 7.1 и ERwin 7.1.

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

Создать отчет согласованности с выбранной методологией (для каждой нотации).

Провести генерацию отчетов по каждому пакету моделирования (BPwin 7.1 и ERwin 7.1.) в форматах HTML и RTF согласно к требованию к курсовому проектированию: вариант в формате RTF включается к приложению в отчете по курсовому проектированию; вариант в формате HTML сдается на электронном носителе руководителю проекта.

Создать приложение в СУБД — ориентированной среде Visual FoxPro 9.0.

Оформить пояснительную записку (в печатном и электронном виде) по разработанному курсовому проекту и представить ее руководителю проекта.

Введение

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

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

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

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

требуемую пропускную способность системы;

требуемое время реакции системы на запрос;

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

простоту эксплуатации и поддержки системы;

необходимую безопасность.

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

Задачи курсового проекта:

разработка концепции информационной системы;

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

покрытие дерева функций функциональными модулями и построение структуры информационной системы в BPwin 7.1;

описание модели функционирования;

создание логической и физической моделей данных в ERwin 7.1;

создание приложения в СУБД — ориентированной среде Visual FoxPro 9.0;

описание функционирования информационной системы.

Глава 1. Экономическая сущность комплекса задач.

1.1 Исследование предметной области ИС.

1.1.1 Определение сущности, целей и задач управления затратами на предприятии В данной курсовой проекте в качестве предметной области рассматривается автоматизированная система учета затрат и ценообразования на производственном предприятие.

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

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

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

Процесс создания системы управления затратами:

Установление связи между системами управления затратами и бюджетного управления;

Определение перспективных направлений снижения затрат;

Разработка плана мероприятий по снижению затрат;

1. Установление связи между системами управления затратами и бюджетного управления:

Внедрение системы бюджетирования;

Предприятие ограничивает размер планируемых затрат, тем самым управляет ими;

Необходимое условие увязкиналичие единого органа управлениябюджетного комитета.

2. Определение перспективных направлений снижения затрат.

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

Анализ структуры затрат (вертикальный, горизонтальный, трендовый) Сравнительный анализ (конкурентами) Анализ носителей затрат т. е. факторов и причин, которое оказывает влияние на сумму затрат по той или иной статье.(технология производства, управление производством).

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

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

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

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

Управление затратами на предприятии призвано решать следующие задачи:

Выявление роли управления затратами как фактора повышения экономических результатов деятельности;

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

1.1.2 Основные принципы, методы построения системы управления затратами.

К числу основных принципов управления затратами относятся:

классификация затрат согласно поставленным управленческим целям;

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

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

затратами;

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

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

недопущение излишних затрат;

широкое внедрение эффективных методов снижения затрат;

совершенствование информационного обеспечения об уровне затрат;

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

снижении затрат;

принцип экономической эффективности;

принцип предупреждения;

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

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

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

1. Факторы спроса, формирующие цену спроса на товар, которую готов заплатить покупатель. К ним относят:

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

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

объём спроса, то есть количество данного товара, которое покупатель обычно приобретает при данном уровне цен;

совокупность потребительских свойств товара (в обычной практике это ассоциируется с качеством товара);

полезность товара — способность удовлетворить определённые.

потребности.

2. Факторы потребительского выбора, определяющие уровень конкурентоспособности данного товара на рынке аналогичных товаров.

В эту группу включаются следующие факторы:

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

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

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

сопоставление конъюнктуры рынка данного товара с дополняющими его товарами или с товарами, для которых данный товар является дополняющим (комплиментарные товары).

Факторы предложения, определяющие цену товара, на которую претендует продавец. К ним относят:

общее количество товара на рынке (фактическая ёмкость рынка) и рыночная доля данного продавца;

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

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

уровень налогообложения для данного вида бизнеса;

среднеотраслевая норма прибыли в данном бизнесе и обычные направления её распределения (инвестиции, фонды, дивиденды).

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

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

предельную замещаемость альтернативных технологий;

предельную замещаемость производственных.

факторов (природных ресурсов, капитала, труда).

5. Факторы эффективности производства и реализации товара, определяющие целесообразность (выгодность) реализации данного бизнеса:

среднеотраслевой уровень рентабельности по данной товарной группе;

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

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

1.1.4 Модель рыночного ценообразования Учет вышеуказанных факторов, а также логика формирования цены товара рыночной экономике реализуется форме модели ценообразования.(см. рис.1).

Рис. 1. Модель рыночного ценообразования Опираясь на данную модель, можно сформулировать основные задачи, решаемые в процессе рыночного ценообразования.

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

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

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

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

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

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

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

8. Учет внешних факторов. На процессы рыночного ценообразования оказывают воздействие факторы, не контролируемые инициатором цены товара — производителем. Основными и наиболее действенными из них являются: меры государственного воздействия при установлении рыночной цены; характеристика типа рынка товаров; инфляционные и другие процессы, обусловливающие предпринимательские риски в процессе установления цены товара. Эти и другие факторы являются объективными ограничителями свободы предприятий при установлении цены на свой товар.

1.2 Описание модели функционирования ИС.

1.2.1 Анализ возможностей методологии и инструментальных средств проектирования заданной ИС Для разработки курсового проекта, предполагается использование таких Case — средств как ERwin и BPwin, которые были разработаны фирмой Logic works. После слияния в 1998 году Logic works c PLATINUM technology они выпускаются под логотипом PLATINUM technology. Для проведения анализа и реорганизации бизнес-процессов PLATINUM technology предлагает case-средство верхнего уровня BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (Data Flow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS, т. е. «как есть») и идеального положения вещей — того, к чему нужно стремиться (модель TO-BE, т. е. «как будет»).

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

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

диаграмма декомпозиции;

диаграмма дерева узлов;

диаграмма только для экспозиции (FEO).

Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент «перекресток», что позволяет описать логику взаимодействия компонентов системы. На основе модели BPwin можно построить модель данных. Для построения модели данных PLATINUM technology предлагает мощный и удобный инструмент — ERwin, хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, PLATINUM technology предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели — механизм двунаправленной связи BPwin — ERwin.

ERwin имеет два уровня представления модели: логический и физический. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных — это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того либо другого.

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

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

— вход (Input): «Данные по затратам», которые представляют собой входную информацию;

— выход (Output) «Бюджетный комитет» и «Ограничение на цены», содержат в себе выходную информацию.

— механизм (Mechanizm), «Бухгалтерская система», которые описывают ресурсы, выполняющие работу и входят в нижнюю грань работы.

— управление (Control), описывают правила, стратегии, процедуры или стандарты, которыми руководствуется работа «Учет затрат и ценообразования на предприятия». Таковыми на диаграмме являются «Факторы влияющие на статьи затрат», «Внешние факторы» входят в верхнюю грань работы.

Контекстная (корневая) диаграмма «Система управления затратами и ценообразования» представлена на рис. 1:

Рис. 1. Контекстная диаграмма А-0.

1.2.3 Диаграммы декомпозиции в методологии IDEF0.

Основной из трех методологий, поддерживаемых BPwin, является IDEF0. Методология IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем.

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

Декомпозиция контекстной диаграммы «Система управления затратами и ценообразования» представлена на рис. 2 и имеет номер А0. Данная диаграмма декомпозиции получается путем детализации контекстной работы на следующие виды работ:

Подсистема управления затратами;

Подсистема управления ценообразованием;

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

Рис. 2. Диаграмма декомпозиции А0.

Декомпозиция работы «Подсистема управления затратами на предприятии» А1 показана на рис. 3 и состоит из следующих работ:

Установление связи между системами управления затратами бюджетного управления;

Определение перспективных направлений снижения затрат;

Разработка плана мероприятий по снижению затрат.

Рис. 3. Диаграмма декомпозиции А1.

Декомпозиция работы «Установление связи между системами управления затратами и бюджетного управления» А1.1 показана на рис. 4 и состоит из следующих работ:

Установление связи между системами управления затратами и бюджетного управления;

Определение перспективных направлений снижения затрат;

Разработка плана мероприятий по снижению затрат;

Рис. 4. Диаграмма декомпозиции А1.1.

Для дальнейшей разработке курсового проекта была проведена еще одна декомпозиции в методологии IDEF0 работы «Разработка плана мероприятий по снижению затрат» (диаграмма А1.3), которая включает следующие работы и представлена на рис. 5:

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

Определение цели управления затратами;

Управление затратами;

Рис. 5 Диаграмма декомпозиции А1.3.

Декомпозиция работы «Подсистема управления ценообразованием» имеет номер А2 (рис. 6).

Эта декомпозиция состоит из следующих работ:

Анализ спроса предложения;

Анализ издержек производства и обращения;

Анализ цен и товаров конкурентов;

Выбор метода расчета цены;

Расчет базовой цены;

Оперативное ценообразование;

Учет факторов ценообразования;

Рис. 6 Диаграмма декомпозиции А2.

1.2.4 Диаграммы декомпозиции в методологии DFD.

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ, их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

функции обработки информации (работы);

документы (стрелки), объекты, сотрудников или отделы;

информации; внешние ссылки (external references);

таблицы для хранения документов (хранилища данных).

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

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

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

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

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

Диаграмма декомпозиции в методологии DFD представлена на рис. 7., которая содержит в себе две хранилища данных: «Финансовые показатели», «Статьи затрат», которые позволяют описать данные, необходимые для сохранения в памяти прежде, чем использовать в работах. Внешняя ссылка «Бухгалтерия» является источником или приемником данных извне модели.

Стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities).

Декомпозиция работы «Расчет базовой цены» имеет номер А2.5. (рис. 7).

В диаграмме потоков данных (рис.7) под названием «Расчет базовой цены» показаны хранилища данных под названиями «Статьи затрат», «Финансовые показатели»," Внешняя ссылка — «Бухгалтер» «Бухгалтерская система» и «Плановый отдел».

Внешняя ссылка «Бухгалтер» и «Плановый отдел» взаимодействует с работами «Расчет базовой цены» в ходе которой производится обмен информацией с БД для проверки расчетной базовой цены товара. Далее, в случае наличия базовой цены, информация о расчете и базовой цены вносится в БД.

Рис. 7 Диаграмма декомпозиции в методологии DFD, A2.5.

Таблицы хранилищ данных можно просмотреть, перейдя в закладку Arrow Data, находящуюся в свойствах потоков данных (рис. 8.).

Рис. 8. Таблицы хранилищ данных, вкладка Arrow Data.

Название сущностей с атрибутами и пояснениями к ним представлены в таблицах 1, 2, 3, 4,5.

Табл. 1. Базы данных.

Табл. 2. Stati-z.

Табл. 3 Material.

Табл. 4 Stati_kalkyl.

Табл. 5 ed-izm.

Далее осуществим экспорт в программу Erwin, для чего в меню File выбираем Export -> ERwin 7.1 (BPX), рис. 9.

Рис 9. Експорт ERwin.

1.2.5 Диаграммы декомпозиции в методологии IDEF3.

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

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

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

Методология IDEF3 была использована при декомпозиции следующих работ «Определение перспективных направлений снижения затрат» (диаграмма А1.2.1), «Управление затратами» (А1.3.3.1) и работа «Учет факторов ценообразования» (А2.7.1).

Диаграмма декомпозиции «Определение перспективных направлений снижения затрат» состоит из следующих работ:

Анализ внешних факторов;

Сбор данных для анализа;

Подготовка проведения анализа структуры затрат;

Подготовка проведения сравнительного анализа;

Проведения анализа носителей затрат;

Проведение вертикального анализа;

Проведение горизонтального анализа;

Проведение трендового анализа;

Проведения сравнительного среднеотраслевого анализа;

Влияние на сумму затрат по конструкции производимого товара;

Влияние на сумму затрат по технологи производимого производства;

Влияние на сумму затрат по управлению производством;

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

Также для IDEF3 используются объекты ссылки, которые выражают некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой.

Пример диаграммы декомпозиции в методологии IDEF3 представлен на (рис. 10).

где используются перекрестки типа Аsynchronous OR. Перекрестки типа Аsynchronous OR под номерами J2 показывает, что предшествующие или следующие процессов должны быть завершены (запущены).

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

Рис. 10. Диаграмма декомпозиции в методологии IDEF3 «Определение перспективных направлений снижения затрат».

Диаграмма декомпозиции «Управление затратами» состоит из следующих работ:

Сбор данных для анализа управления затратами;

Определение затрат по основным этапам ЖЦ продукта и функциям управления;

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

Подготовка информационной базы;

Определение технических способов и средств снижения, измерения и контроля затрат;

Выявление резервов снижения затрат на всех этапах произв. пр-са и во всех производственных подразделениях.

Выбор способов нормирования затрат и выбор системы управления затратами.

Декомпозиция работы «Управление затратами» имеет номер А1.3.3.1. (рис. 11).

Также использовались перекрестки типа Аsynchronous OR. Перекрестки типа Аsynchronous OR под номерами J4 показывает, что предшествующие или следующие процессов должны быть завершены (запущены).

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

Рис. 11. Диаграмма декомпозиции в методологии IDEF3 «Управление затратами».

Еще одним процессом, требующим декомпозиции в методологии IDEF3, является работа «Учет факторов ценообразования». Она включает в себя следующие работы:

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

Анализ факторов ценообразования;

Учат факторов спроса;

Учет потребительского выбора;

Учет факторов предложения;

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

Учет факторов эффективности;

Определение факторов ценообразования;

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

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

Рис. 12. Диаграмма декомпозиции в методологии IDEF3 «Учет факторов ценообразования».

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

Для создания сценария необходимо перейти в пункт меню Diagram ->Add IDEF3 Scenario, выбрать соответствующую диаграмму декомпозиции и поставить галочку на пункте «Copy contents of source diagram». Удаляем ненужные работы, стрелки и перекрестки, не входящие в сценарий. На рисунках 12, 13, 14 показаны диаграммы сценариев под номерами А1.2.2, А1.3.3.2 и А2.7.2, созданные на основе диаграмм IDEF3.

Рис. 13. Сценарий диаграммы декомпозиции в методологии IDEF3 «Управление затратами».

Рис. 14. Сценарий диаграммы декомпозиции в методологии IDEF3 «Учет факторов ценообразования».

1.2.6 Функционально-стоимостной анализ.

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

B BPwin модуль ABC применяется для:

понимания происхождения выходных затрат и определения их стоимости;

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

определения требуемых ресурсов;

определение действительной стоимости поддержки клиента;

оценки и анализа затрат на осуществление различных видов деятельности;

облегчения выбора оптимальной модели процесса при реорганизации деятельности предприятия;

выделения наиболее дорогостоящих операций для их реинжиниринга.

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

ABC включает следующие основные понятия:

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

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

— центры затрат — различные статьи расходов.

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

последовательная — следует синтаксическим правилам IDEF0;

корректная — полностью отражает процесс;

полная — охватывает всю рассматриваемую область.

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

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

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

Рис. 15. Центры затрат, используемые в курсовом проекте Описание Cost Center представлено в таблице 6.

Табл. 6. Cost Center.

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

Рис. 16. Диаграмма декомпозиции с приведенной стоимостью Поскольку невозможно продемонстрировать функционально-стоимостной анализ на каждой работе, составим отчет с помощью пункта меню Tools-ReportsActivity Cost Report, и задавая соответствующие параметры получим следующий отчет, представленный на рис. 17.

Рис. 17. Фрагмент отчета по функционально-стоимостному анализу Данные о проведенном функционально-стоимостном анализе на работах методологии IDEF0 представлены в таблице 7.

Табл. 7. Стоимостной анализ.

1.2.7 Диаграмма FEO и диаграмма дерева узлов Диаграммы «только для экспозиции» часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEFO. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку, по сути, являются картинками — копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и входа. С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и с одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Если FEO используется для иллюстрации альтернативных точек зрения, рекомендуется придерживаться синтаксиса IDEFO. Диаграммы FEO представлены на рис. 18.

Рис. 18. Диаграмма FEO работы «Установление связи между системами управления затратами и бюджетного управления».

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

На рис. 19. показана диаграмма дерева узлов.

Рис. 19. Диаграмма дерева узлов.

1.2.8 Организационная диаграмма.

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

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

Добавление организационной диаграммы в модель производится по команде Diagram/Add Organization Chart. В результате организационная диаграмма примет вид, изображенный на рис. 20.

Рис. 20. Организационная Диаграмма Swim Line диаграмма Диаграмма Swim Lane является разновидностью диаграммы IDEF 3, и применяется в BPwinмоделях для улучшения понимания содержания модели организационной структуры (Organization Chart) и явного описания роли и ответственности исполнителей в конкретной технологической операции Диаграмма представляет собой графические изображения особенностей процесса в виде нескольких горизонтальных дорожек (свимлэйн), которые получили название «роли». Каждая из дорожек означает конкретный структурный объект, и на ней изображаются функции процесса, выполняемые данным объектом. На дорожках могут присутствовать любые объекты IDEF3-диаграммы, относящиеся к соответствующей роли, а на нижней дорожке, обычно, изображаются средства автоматизации функций процесса. Полоса может содержать объекты диаграммы IDEF3 (UOW, перекрестки и объекты ссылок), относящиеся к соответствующей роли или UDP типа Text List.

Для создания диаграммы Swim Lane выберите меню Diagram/Add Swim Lane diagram.

Появляется гид Swim Lane diagram Wizard. В первом диалоге гида следует внести название и имя автора диаграммы, выбрать имя и номер диаграммы IDEF3, на основе которой будет построена диаграмма, и группу ролей, из которой можно будет выбрать роли, связанные с диаграммой. Во втором диалоге гида следует выбрать роли, на основе которых будет создана диаграмма. Диаграмма будет разделена на количество полос, указанных в колонке Display Swim Lane. После щелчка по кнопке Finish создается новая диаграмма, все объекты которой расположены произвольно. Расположить объекты на полосах, соответствующих ролям, следует вручную. Результат диаграммы представлен на рис. 21.

Рис. 21. Диаграмма Swim Line.

Глава 2. Информационная система и ее описание.

2.1 Информационная модель в нотации IDEF1.X.

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

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

ER-диаграммы были приняты в качестве основы для создания стандарта IDEF1X. Предварительный вариант этого стандарта был разработан в военно-воздушных силах США и предназначался для увеличения производительности при разработке компьютерных систем. В 1981 г. этот стандарт был формализован и опубликован организацией ICAM, и с тех пор является наиболее распространенным стандартом для создания моделей баз данных по всему миру.

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

Case-средство ERwin поддерживает методологию IDEF1X и стандарт IE. Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных систем. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем «сверху вниз». Три уровня модели, объединяющие в себе логические модели, состоят из диаграммы сущность-связь, модели данных, основанной на ключах и полной атрибутивной модели. Цель модели диаграмма сущность-связь — формирование общего взгляда на систему для ее дальнейшей детализации.

2.1.1 Логическая модель Логическая модель позволяет понять суть проектируемой системы, отражая логические взаимосвязи между сущностями.

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

— диаграмма сущность-связь (Entity-Relationship Diagram (ERD);

— модель данных, основанная на ключах (Key Based Model (KB);

— полная атрибутивная модель (Fully Attributed Model (FA).

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

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

Диаграмма сущность-связь представлена на рис. 22.

Рис. 22. Диаграмма «Сущность-связь».

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

Модель данных, основанная на ключах представлена на рис. 23.

Рис. 23. Модель данных, основанная на ключах Нижний уровень состоит из Transformation Model (Трансформационная модель) и Fully Attributed (Полная атрибутивная модель). Трансформационная модель содержит всю информацию для реализации проекта, который может быть частью общей информационной системы и описывает предметную область. Трансформационная модель может проектировать и администрировать БД, представлять какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям информационной системы. Фактически из трансформационной модели автоматически можно получить модель СУБД, которая является точным отображением системного каталога СУБД.

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

Полная атрибутивная модель данных (или модель данных в третьей нормальной форме) представлена на рис. 24.

Рис. 24. Полная атрибутивная модель.

2.1.2 Физическая модель.

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

Модель СУБД напрямую транслируется из трансформационной модели, являясь отображением системного каталога. ERWin напрямую поддерживает эту модель через функцию генерации схемы БД. При составлении схемы БД в качестве индексов могут использоваться как ключевой атрибут, так и остальные поля БД (рис. 25).

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

Для рассмотрения видов нормальных фор введем понятия функциональной и полной функциональных зависимости.

Функциональная зависимость — Атрибут В сущности Е функционально зависит от атрибута, А сущности Е, если и только если каждое значение, А в Е связало с ним точно одно значение В в Е. другими словами, А однозначно определяет В.

Полная функциональная зависимость — Атрибут Е в сущности В полностью функционально зависит от ряда атрибутов, А сущности Е, если и только если В функционально зависит от, А и не зависит ни от какого подряда А.

Существуют следующие виды нормальных форм:

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

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

Третья нормальная форма (3NF). Сущность Е находится в третьей нормальной форме, если она находится во второй нормальной форме и неключевые атрибуты сущности Е зависят от других атрибутов Е.

Физическая модель создается на основе логической путем генерации, то есть подключение и установление связи с соответствующей СУБД. В нашем случае была использована СУБД Visual FoxPro 9.0. Первоначально физическая модель создавалась параллельно с логической, и, как известно, она является трансформационной моделью.

Трансформационная модель представлена на рис. 25.

Рис. 25. Трансформационная модель (логический уровень) Далее, в пункте меню Database/Choose Database и выбрать соответствующую СУБД (рис. 26).

Рис. 26. Выбор СУБД для генерации физической модели Предварительная физическая модель примет вид (рис.26).

Рис. 27. Трансформационная модель (физический уровень) Генерация физической модели Процесс генерации физической схемы базы данных из модели данных называется прямым проектированием (Forward Engineering). При генерации схемы кроме таблиц и представлений ERwin DM создает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие объекты, доступные для выбранной СУБД.

Для генерации системного каталога базы данных следует перейти на физический уровень модели и выбрать пункт меню Tools/Forward Engineer/Schema Generation или нажать кнопку на панели инструментов Database Toolbar (команда Forward Engineer в меню Tools доступна лишь на физическом уровне модели). Появляется диалог Forward Engineer Schema Generation, включающий закладки: Options, Summary, Comment (рис. 28).

Рис. 28. Диалог Forward Engineer Schema Generation.

В закладке Options устанавливают опций генерации объектов базы данных — таблиц, колонок, индексов и т. д. Для задания опций генерации какого-либо объекта следует выбрать объект в левом списке закладки, затем включить соответствующую опцию в правом списке. В данном случае для объекта Table выбираем опцию CREATE TABLE, для Column — Physical Order, для объекта Index — Create Index/Primary Key (PK) (рис. 29,30,31). Объект Referential Integrity остается неизменным.

Рис. 29. Опции для объекта Column.

Рис. 30. Опции для объекта Index.

В закладке Summary отображаются все опции, выбранные в закладке Options. Список опций в Summary можно редактировать так же, как и в Options. Закладка Comment позволяет внести комментарий для каждого набора опций.

Каждый набор опций генерации может быть именован и использован многократно. Для загрузки, создания, переименования и удаления собственных наборов опций генерации используют комбинированный список Option Set и кнопки Open, Save, Save As и Delete диалога Forward Engineer Schema Generation.

Кнопка Preview вызывает диалог Schema Generation Preview (рис. 30), в котором отображается SQL-скрипт, создаваемый ERwin DM для генерации системного каталога СУБД.

Рис. 31. Диалог Schema Generation Preview.

Кнопка Generate запускает процесс генерации схемы. Возникает диалог подключения к базе данных SQL Server Connection (рис. 32), в котором устанавливают параметры подключения. Нажимая на кнопку Connect, устанавливают сеанс связи с баз данных и инициируют выполнение SQL-скрипта.

Рис. 32. Диалог подключения к базе данных Открывается диалог Generate Database Schema, отображающий ход процесса генерации (рис. 33). По умолчанию в диалоге включена опция Stop If Failure. Это означает, что при первой ошибке выполнение скрипта прекращается. Кнопка Abort прерывает выполнение. При выключенной опции Stop If Failure скрипт будет выполняться, несмотря на встречающиеся ошибки.