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

Содержание:

Введение

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

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

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

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

1. Постановки задачи и выбор средств проектирования

1.1. Описание предметной области. Постановка задачи

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

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

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

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

Исходя из выше изложенного, можно сделать некоторые выводы.

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

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

Склад не ведет коммерческой деятельности, а только хранить продукцию.

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

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

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

–входные данные:

1)Счета-фактуры поставщиков на продукции

2)Заявки покупателей

3)Платежные поручения покупателей

4)Приходная накладная

–выходные данные

1)Счета на оплату по заказам

2)Договора поставки

3)Счета-фактуры покупателям на реализованную продукцию

4)Заявки поставщикам

5) Платежные поручения по оплате поставщикам

Согласно выделенным функциям систему можно разделить на три части:

–подсистема хранения данных, для непосредственного хранения сведений о товаре на складе

–подсистема расчета, которая показывает информацию о том что полученный заказ или товар оплачен

–подсистема формирования отчетов ,для статистики и анализа работы склада

Полученное деление позволяет выделить следующие роли/ сотрудник, взаимодействующие в процессе работы склада:

–Бухгалтерия: оплачивает счета о закупки товара

–Менеджер по поставкам: заключает договора с поставщиками товара

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

–Различных типов грузчики осуществляют прием и размещение товара на складе и его отгрузку.

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

1.2. Выбор средства для моделирования бизнес-процессов

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

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

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

На данный момент представлено большое количество средств, позволяющих описать бизнес процесс(ARIS, AllFusionModelingSuite, RationalRose и др.)

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

В качестве примера сравнительного анализа методов ARIS и IDEF(IDEF0, IDEF3) и их инструментальные средства ARIS Toolsetи BPwin.

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam - это Integrated Computer-Aided Manufacturing) и алгоритмические языки. Основные типы методологий моделирования и анализа бизнес-процессов:

• Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов – стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.
• Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.
• Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.
• Прочие методологии.

В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.

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

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

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

Основная бизнес-модель ARIS - eEPC (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS eEPC является расширением нотации IDEF3. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть проинформирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.

Основные объекты нотации eEPC:

• Функция. Служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. Каждая функция должна быть инициирована событием и должна завершаться событием; в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.
• Событие. Служит для описания реальных событий, воздействующих на выполнение функций.
• Организационная единица. Например, управление или отдел.
• Документ. Отражает реальные носители информации, например, бумажные документы.
• Прикладная система.
• Кластер информации. Характеризует набор сущностей и связей между ними.
• Связь между объектами. Тип отношений между объектами, например, активация выполнения функции некоторым событием.
• Логический оператор. Оператор «И», «ИЛИ» или исключающее «ИЛИ», позволяет описать ветвление процесса.

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

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

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

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

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

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

Сравнивая инструментальные средства ARIS Toolsetи BPwin. Необходимо отметить что, для хранения данных ARIS Toolset использует объектную СУБД, а BPwin файлы. От чего BPwin упрощает создание модели, но ограничивает возможность анализа.

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

Таким образом, для введения небольших по масштабам и длительности проектов рационально использовать BPwin. Для крупных проектов больше подходит ARIS.

Если рассматривать инструментальное средство BPwin, то на данный момент существует AllFusionProcessModeler 7– мощный программный продукт с помощью которого, можно  проводить моделирование, анализ, описание и последующую оптимизацию бизнес-процессов.  С помощью BPwin можно создавать графические модели бизнес-процессов.

BPwin (AllFusion Process Modeler 7) – это продукт компании Computer Associates,  он вместе с ERwin Data Modeler (ERwin), Model Manager (ModelMart) и Data Model Validator (ERwin Examiner), входит в пакет программ AllFusion Modeling Suite.

С помощью BPwin можно провести оптимизацию деятельности предприятия и осуществить проверку на соответствие ее стандартам ISO 9000, создать проект организационной структуры, исключить ненужные операции, уменьшить размер издержек и увеличить эффективность.

В основе программного продукта  BPwin (AllFusionProcessModeler 7) заложены общепринятые технологии моделирования, такие как idef0. Моделирование с помощью методологии idef0 рекомендовано к использованию Госстандартом Российской Федерации и  является общепринятым стандартом в США.

Подведя итог выше изложенному сравнительному анализу методов ARIS и IDEF(IDEF0, IDEF3) и их инструментальные средства ARIS Toolset и BPwin делаем выбор в пользу BPwin и метода IDEF.

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

1.3. Моделирование бизнес-процессов «как есть»

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

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

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

Исправление недостатков, модернизация существующих процессов приводит к созданию модели как будет (TO-BE).

Только на основе модели «как будет» проектируется ER модель данных и а потом и вся информационная система. Построение модели на основе модели «как есть» приводит к тому, что информационная система автоматизирует неправильно работающие убыточные процессы.

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

Начинаем моделирование с построения контекстной диаграммы. Для этого используется Нотация IDEF0.

Согласно Методологии функционального моделирования[3]

Нотация IDEF0 (IntegrationDefinitionforFunctionModeling) была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий.

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

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

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

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

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

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

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

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

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

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

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

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

Последовательность действий товарооборота на Складе такова:

1)Менеджеры по закупкам формируют заказы товаров и передают сведения на склад

2)Бухгалтерия оплачивает счета и передает соотвествующие ордеры и накладные на склад

3)Кладовщики принимают товар согласно имеющей у них информации

4)Грузчики осуществляют разгрузку и погрузку товара на складе

5)Кладовщик фиксирует все операции на складе и формирует соответствующие документы и отчеты.

Склад использует информационную систему, которая позволяет отследить движения товара.

Подводя итог выше изложенному анализу предметной области построим IDEF0 Склад.

И так что же во общем представляет из себя Cклад на IDEF0. Это некий черный ящик, который на входе получает некий документ-запрос на прием или получение товара. Для которой в качестве ограничения выступают какие-то инструкции( например должностные инструкции или устав организации), а в качестве ресурсов выступает информационная система Склада. На выходе мы получаем некий документ о том, что товар выдан или получен.

Переводим все выше сказанное в контекстную диаграмму( Рисунок 1).

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

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

Декомпозируем контекстную диаграмму на 3 функциональных блока (Рисунок 2):

Рисунок 2.Диаграмма IDEF0

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

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

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

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

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

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

Любая DFD-диаграмма может содержать работы, внешние сущности, стрелки (потоки данных) и хранилища данных.

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

Декомпозируем функциональный блок «Приемка товара на склад» еще на четыре действия (Рисунок 3):

Рисунок 3 . DFD Приемка товара на склад

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

– Проверка поставленной продукции: подразумевает непосредственную проверку товара на количество, указанное в документах и информационной системе;

– Занесение данных о продукции в БД: подразумевает факт фиксации информации о поступлении товара на склад;

– Передача продукции на хранение: проверенная продукция передается на хранение в соответствии с условиями хранения.

Далее декомпозируем функциональный блок «Хранение и переучет продукции» на два действия (Рисунок 4):

Рисунок 4 . DFD Хранение и переучет продукции

– Размещение товара на складе: подразумевает физическое размещение товара на складе и фиксация этой информации в системе;

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

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

Рисунок 5 . DFD Отгрузка

– Проверка наличия товара на складе: проверка сведений в системе о количестве в данный момент товара на складе для выполнения заказа( достаточно его или нет, нет товара совсем);

– Занесение информации об отгружаемой продукции в БД: фиксация сведений о дате отгрузки товара и количестве его;

– Отгрузка продукции по требованию: непосредственно передача товара для дальнейшей его реализации.

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

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

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflowdiagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов[7].

IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать «сеть переходных состояний объекта», предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс[7].

Проведем декомпозицию блока «Проверка товарно-транспортной накладной» который, является элементом разбиения блока «Приемка товара на склад» на четыре действия:

–Принятие товарно-транспортной накладной: проверка документации поставщика;

–Проверка поставщика: уточнение информации о поставщике;

–Проверка реквизитов документа: проверка основных реквизитов документов, для уточнения сведений об оплате товара;

–Проверка количества продукции: сколько прописано в документах и сколько в действительности пришло товара .

Рисунок 6. IDEF3 проверки товарно-транспортной накладной.

Рисунок 7. IDEF3 проверки поставленной продукции

Проведем декомпозицию блока «Проверка поставленной продукции» который, является элементом разбиения блока «Приемка товара на склад» на три действия:

–Проверка продукции на годность, то есть проверить качество поступившей продукции;

–Принять продукцию: принимается решение о принятие продукции или возврату поставщику;

–Вернуть поставщику: в случаи обнаружения ошибки в реквизитах документов, несоответствии поступившего количества и оплаченного.

2. Модернизация функционирования склада

2.1.  Предлагаемые мероприятия по улучшению бизнес-процессов

Любая организация хочет оставаться лучшей в своей сфере деятельности. Для того чтобы быть конкурентно способной, необходимо совершенствоваться. Что предполагает улучшение или изменение существующих процессов. Модернизация системы это всегда сложно, особенно если организация большая. А любой склад – это большой взаимосвязанный элемент бизнеса. И от качества получаемых материалов или товаров зависит качество производства или оказания услуг. Поэтому очень важно от качества товара/материала, поступаемого на склад, и упаковки при отправки заказа. Если хоть один элемент этой системы допустит ошибку, например не верно указать количество поступившего товара на склад, будет иметь огромные последствия для работы системы в целом.

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

В ходе анализа системы были выделены следующие проблемные места:

– ошибки персонала при работе с документами: человек может не заметить ошибки в документах;

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

– длительность обработки информации всеми возможными ролями;

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

Все выше перечисленные проблемы можно избежать простроив единую информационную систему. А так же обеспечение информационной безопасности и соблюдение законодательства Российской Федерации.

Теперь более детально рассмотрим контекстную диаграмму( Рисунок 1) и декомпозированную диаграмму IDEF0( Рисунок 2). Диаграммы имеют некоторые упущения и требуют доработки.

На контекстной диаграмме( Рисунок 1) нигде не учитывается возврат товара как клиентом, так и поступлением брака на склад.

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

Товар может быть списан, например в связи с истечением срока хранения. Что не отображено на выходе модели.

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

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

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

А вот информационная система в данном случае не является ресурсом, так как сама по себе она скорее является банком сведений об операциях склада, а не источником.

2.2  Моделирование бизнес процессов «как должно быть»

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

И так модернизируем созданную ранее контекстную диаграмму( Рисунок 1) с замечаниями указанными в разделе 2.1. и получаем усовершенствованную контекстную диаграмму( Рисунок 8)

Рисунок 8. Контекстная диаграмма функционирования склада

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

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

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

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

Согласно усовершенствованной контекстной диаграммы проведем декомпозицию и получаем IDEF0 Деятельность склада декомпозированная( Рисунок 9)

Рисунок 9.  IDEF0 Деятельность склада декомпозированная

Весь процесс деятельности склада можно разделить на:

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

– Хранение (основная функция склада). Означает прием товара от поставщика и его размещение на складе. Фиксация о размещении в системе. Создание всех необходимых условий для хранения товара. Необходима декомпозиция блока.

–Отгрузку и возврат товара. Склад либо принимает товар от поставщика к себе на хранение, либо клиент возвращает по каким-либо причинам товар на склад.

Проводим декомпозицию блока Хранения и в результате разбиения получаем IDEF0 Хранение (Рисунок 10):

Рисунок 10.  IDEF0 Хранение декомпозированая

Процесс хранения можно разделить на:

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

– Складирование (непосредственное размещение товара на складе). Означает, что товар прошел все проверки и соответствует заявленным требованиям и документация вся в порядки. В соответствии с условиями хранения товара, он размещается на складе. Место размещения, количество и дата фиксируются в системе.

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

– Списание товара. Процедура выполняется при наборе определенного количества, например бракованного товара или с истекшим сроком хранения.

По полученному описанию можно сказать, что блок Складирование можно декомпозировать еще (Рисунок 11):

Рисунок 11.  IDEF0 Складирование декомпозированная

IDEF0 Складирования делиться на:

–Складирование на оптимальный склад. На данном этапе, проверенный товар размещается на складе. Товар прошёл все проверки и существенных дефектов не найдено, документы так же в порядке.

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

– Формирование возвратных документов. Если товар не прошел проверку и приемки или были выявлен брак в ходе комплектации заказа клиенту или же клиент вернул товар по каким-либо причинам формируются документы для оформления возврата поставщику.

Заключение

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

Список использованной литературы

1. Волгин В.В. Склад .Управление – М.:Литрес,2013. 430 с
2. Маклаков С.В. BPwin и Erwin: CASE – средства для разработки информационных систем. М.: Диалог-МИФИ, 1999. — 256 с.
3. Методология функционального моделирования IDEF0. М.,2000. – 75 с.
4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп.– М.: Финансы и статистика, 2006. – 544 с: ил.
5. Хаммер М. Реинжиниринг корпорации: манифест революции в бизнесе: Пер. с англ. / М. Хаммер, Дж. Чампи Дж. – М. : Изд-во «Манн, Иванов и Фербер»,2006. – 287 с.
6. Робсон М. Практическое руководство по реинжинирингу бизнес-

процессов / М.: Робсон, Ф. Уллах : пер. с англ. / под ред. Н.Д. Эриашвили. – М. :Изд-во «Аудит», ЮНИТИ, 2007. – 224 с.

1. Стандарты IDEF. Электронный ресурс. Режим доступа www.igef.ru
2. Черемных С.В., Семенов И.О., Ручкин В.С.: Моделирование и анализ систем. IDEF-технологии – М.: Финансы и статистика, 2006. – 188 с.
3. Ипатова Э.Р., Ипатов Ю.В. Проектирование информационных систем: Учебное пособие.— Магнитогорск: МаГУ, 2003. — 187 c.
4. Ипатова Э.Р., Ипатов Ю.В. Практикум по проектированию информационных систем: Учеб. пособие. – Магнитогорск: МаГУ, 2004. – 116
5. Официальный сайт компании AIRIS. Электронный ресурс. Режим доступа www.ariscommunity.com
6. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. М.: Диалог-МИФИ, 2002. — 224 с.