Преподаватель который помогает студентам и школьникам в учёбе.

Разработка регламента выполнения процесса «Покупка сырья и материалов» (Описание предметной области)

Содержание:

Введение

Закупка товаров предприятием или торговой организацией – наиболее проблемный этап схемы обеспечения материальными ресурсами. В статье про выбор оптимальной схемы обеспечения предприятия материальными ресурсами мы описали своё видение идеи организации учета, общую концепцию. Чтобы максимально сократить издержки при хранении ТМЦ, но при этом гарантировать обеспеченность материалами производственного или торгового процесса, необходимо часть закупок ТМЦ осуществлять адресно (надо -› купили), а часть – для восполнения запасов, которые можно оперативно использовать, снижая зависимость от возможных задержек поставок (надо -› берем с запаса на складе -› покупаем -› восполняем запас).

Целью данной работы является Разработка регламента выполнения процесса «Закупка сырья и материалов».

Задачи работы – построить:

- развернутое (подробное) описание предметной области;

- диаграмму вариантов использования;

- диаграмму деятельности;

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

- диаграмму состояний;

- диаграмму классов

Глава 1. Описание предметной области

Большинство действий (этапов), которые осуществляются при закупке товарно-материальных ценностей, однотипны:

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

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

комплексное планирование поставок (закупок) в целом по предприятию;

подбор поставщиков, тендерные процедуры;

поставка ТМЦ (оформление, контроль соблюдения условий поставки, оприходование на учет, ...);

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

Чаще всего эти этапы процесса закупки выполняются последовательно. Но на любом из них может быть откат назад. Например, при проблемах поставки может понадобиться заново искать поставщика. Кроме того, в любой момент может возникнуть что-то, что невозможно было предугадать, например, аварийная ситуация. А значит необходимо быть готовым к срочному внесению изменений во все планы (обеспечения, поставок/закупок), срочному подбору поставщика и осуществления внеплановой закупки ТМЦ.+

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

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

Осуществить планирование материального обеспечения предприятия – значит заранее определиться, какие ТМЦ и в каких объемах нам будут нужны. Лучший (наверно даже единственный) способ выполнить планирование обеспечения материальными ресурсами – обдумать заранее, что мы будем делать (изготавливать, Иногда не возможно на этапе материально-технического планирования определиться с точным объемом требуемых ТМЦ или даже с тем, какие ТМЦ потребуются. Во многих случаях эта проблема решается за счет создания текущего оборачиваемого запаса – небольшого запаса постоянно используемых товаров, которые мы всегда имеем в наличии (на сайте можно найти статьи о пользе нормирования запасов, а также о том, какие виды запасов мы рекомендуем для применения на практике).

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

Для того, чтобы зафиксировать имеющуюся потребность в ТМЦ, мы применяем "заказы" – электронные документы, которыми конечные потребители заказывают необходимые им ТМЦ. При оформлении заказов крайне важно определиться с источником обеспечения, т.е. то, откуда мы возьмем необходимые ТМЦ. В своей практике мы используем 5 источников обеспечения. Кроме закупки это еще адресный резерв, собственное производство и два вида запасов – запас текущий оборачиваемый и запас аварийный. Детальнее с рекомендуемой нами схемой планирования потребности в материалах и заказе ТМЦ можно познакомиться в статье о планирование потребности в ТМЦ (заказ ТМЦ и источники обеспечения).

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

2. ПОДАЧА ЗАЯВОК НА ЗАКУПКУ

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

Детально преимущества от раздельного оформления заказов и заявок мы рассмотрим немного позже. Вот некоторые из преимуществ:

неоспоримые управленческие выгоды от четкого понимания, для чего требуются те или иные закупаемые ТМЦ;

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

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

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

Заявка на закупку также крайне важна для оценки эффективности организации и проведения закупок (сравнения плана и факта поставок). В данном случае контроль выполнения заявки без сложностей может быть проведен самим заказчиком, т.е. подразделением, которое подало заявку на закупку ТМЦ. А ведь именно контроль закупки заказчиком/потребителем, т.е. лицом, которое зависит от наличия затребованных ТМЦ, часто является наиболее эффективным. Нужно только дать этому лицу возможность своевременно видеть проблемы с закупками и объективно их оценивать.

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

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

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

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

Выделение плана закупок в схеме закупок ТМЦ обеспечивает и многие прочие выгоды, например, возможность организовать автоматический контроль за оприходованием позиций, не заявленных к закупке, т.е. предотвратить «самодеятельность» снабженцев при закупках, когда покупают "не совсем" то, что надо (или совсем не то), или когда закупка товаров ведется в завышенном объеме

Отсутствие контроля сроков подбора поставщиков может привести к тому, что обоснование задержки поставки ТМЦ будет постоянно списываться именно на проблемы в поиске поставщика. Поэтому желательно иметь четкие и эффективные механизмы анализа задержек при подборе поставщиков.

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

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

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

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

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

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

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

Глава 2. Выбор средства моделирования

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

Язык UML объединил наиболее известные методы OOA/OOD и очень быстро приобрел широкую популярность среди разработчиков программного обеспечения.

Основными «строительными блоками» UML являются диаграммы, которые условно можно разделить на две категории:

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

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

Моделирование бизнеса с помощью UML предполагает по-следовательное построение двух видов моделей:

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

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

Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

диаграммы поведения системы (behavior diagrams):
диаграммы взаимодействия (interaction diagrams):
диаграммы последовательности (sequence diagrams) и
кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;
диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; – диаграммы реализации (implementation diagrams):
диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В данном учебном пособии для примера моделирования системы выбран программный инструмент моделирования StarUML [7]. Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML [7]. StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (модельно- настраиваемая архитектура), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.

Инструмент поддерживает возможность добавить плагины к базовой системе. Несмотря на то, что записано на языке Delphi, эти плагины могут быть записаны на любом COM-совместимом языке, таком как C++, Delphi, C# и VB.

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

Из прочих достоинств можно выделить:

- Генерация кода в языки: C#, Java, С++

-Поддержка работы с фреймворками

-Удобный графический редактор

-Полное соответствие стандарту UML 2.0

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

-Экспорт документации в форматы: DOC, PPT, TXT, XLS…

- Поддержка паттернов

- Импорт проектов Rational Rose

- Приятный размер дистрибутива

Глава 3. Построение диаграмм

Диаграмма вариантов использования системы

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

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

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

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

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

Рисунок 1 – Диаграмма вариантов использования для системы «Салон красоты»

Диаграмма деятельности системы

Деятельности

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

Рисунок 2 – Диаграмма деятельности системы

Диаграмма последовательности системы

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

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

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

При этом прием сообщения инициирует выполнение определенных действий тем объектом, которому сообщение передано.

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

Анализ диаграммы последовательности помогает выявить все обязательства активного объекта.

Рисунок 3 – Диаграмма последовательности системы

Диаграмма классов

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

После исследования предметной области выявили следующие классы (рис 4.):

Рисунок 4 – Классы системы

Атрибут – это элемент информации, связанный с классом.

Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).

Рисунок 5 – Атрибуты классов системы

Установим отношения между классами (рис.6):

Рисунок 6 –Диаграмма классов системы

Диаграмма состояния:

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

Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. Наиболее распространенная форма, используемая в объектно-ориентированных методах, впервые применялась в методе ОМТ и впоследствии была адаптирована Гради Бучем.

Рис. 7. Диаграмма состояний системы

Заключение

В результате выполнения курсовой работы была выполнена разработка регламента выполнения процесса «Закупка сырья и материалов». Были изучены и построены следующие диаграммы:

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

Список литературы

Кознов Д.В Языки визуального моделирования: проектирование и визуализация программного обеспечения. Учебное пособиеСПб.: Изд-во СПбГУ, 2004, 143 с
Буч Г., Якобсон А., Рамбо ДжUML 2.0СПб.: Питер, 2006, 735 с
UML 2.0 Infrastructure SpecificationMarca D.A., McGowan C.LSADT Structured Analysis and Design Technique McGraw-Hill, 1988
Якобсон А., Буч Г., Рамбо Дж Унифицированный процесс разработки програмСПб.: Питер, 2002, 492 с
Фаулер М., Скотт К UML. ОсновыСПб.: Символ, 2006, 184 с
Леоненков А.ВОбъектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006, 319 с
Павлинов А., Кознов Д., Перегудов А., Бугайченко Д., Казакова А., Чернятчик Р., Фесенко Т., Иванов АО средствах разработки проблемно-ориентированных визуальных языков. Сб. «Системное программирование», Вып. 2
Гамма Э., Хелм Р., Джонсон Р., Влиссидес ДжПриемы объектно-ориентированного проектированияИзд-во Питер, 2005, 368 с