Файл: Разработка регламента выполнения процесса «Складской учет» (Моделирование бизнес-процессов).pdf

1. Наличие продукта (процедуры), относительно которого необходимо выделить бизнес - процесс.

2. Потребность руководства в управленческой информации относительно данного бизнес - процесса.

3. Существующая система бухгалтерского и управленческого учета.

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

5. Наличие персонала, способного выполнять ролевые функции в команде.

К требованиям и ограничениям процесса моделирования нового бизнес – процесса складского учета следует отнести такие:

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

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

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

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

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

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

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

- приема товара на склад от поставщика;

- комплектация и выдачу товаров со склада;

- инвентаризацию товаров на складе (при условии его комплексной автоматизации).

Основные объекты в процессе продажи товара

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

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

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

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

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

1.3. Требования к автоматизированной системе

Программа должна обеспечивать выполнение перечисленных ниже функций:

Для покупателя:

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

Для работников магазина:

• • 1. Контроль над безопасностью (выдача паролей);
    2. Обеспечить различные права доступа сотрудникам магазина;
    3. Закупить товар;
    4. Продать товар;
    5. Перемещение товара (со склада на склад, со склада в магазин, с магазина в магазин, из магазина на склад);
    6. Поиск товара по его наименованию;
    7. Формирование и печать накладных (расходных, приходных), прайс-листа.

Требования к временным характеристикам программы не предъявляются.

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

Выходные данные программы – накладные, прайс-листы.

Накладные и прайс-листы должны быть представлены в виде отдельных файлов *.txt, организованных определенным образом.

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

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

• организацией бесперебойного питания технических средств; использованием лицензионного программного обеспечения;
• регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998г. "Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств";
• регулярным выполнением требований ГОСТ 51188-98. Защита информации;
• испытания программных средств на наличие компьютерных вирусов;
• спецификация по безопасности;
• отказы из-за некорректных действий оператора.

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

• Идентификация пользователя для входа в программу.

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

Минимальные требования к оборудованию:

• Процессор: Pentium 90 МГц;
• Объем оперативной памяти: 256 Мб;
• Свободного места на диске 10-15 Мб.

Требования к операционной системе:

• Microsoft Windows XP и выше.

Требования к программному обеспечению:

• Bor1and De1phi 7.0

Требования к пользователю:

• Опытный пользователь ПК с опытом работы в розничной торговле.

2 Глава. Построение бизнес-процессов

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

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

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

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

Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма – это описание сценария поведения, которому следуют действующие лица (Actors). Отражает объекты, как системы, так и предметной области и задачи, ими выполняемые. [Приложение 1]

На диаграмме изображены следующие действующие лица (актеры):

1. поставщик;
2. зав.складом;
3. переупаковщик;
4. грузчики;
5. тмц;
6. отдел инвентаризации;
7. подразделение.

Диаграмма показывает процесс работы склада и передвижение (товарно-материальных ценностей). Весь процесс описывается следующим образом: Актер «Поставщик» поставляет товарно-материальную ценность актеру «Зав.складом», «Подразделение» отправляет заказ на товарно-материальную ценность актеру «Зав.складом», он поставляет товарно-материальную ценность на склад (принимает «Зав.складом»), «Зав.складом» отправляет товарно-материальную ценность на переупаковку актёру «Переупаковщик», но только в том случае если «Переупаковщик» получит «заявку на переупаковку», в противном случае «Зав.складом» отправляет заявку на размещения товарно-материальной ценности «Грузчикам 1-го отдела» которые, в свою очередь, непосредственно размещают товарно-материальную ценность. Далее товарно-материальную ценность перемещают в зону отгрузки, там ее принимают «Грузчики 2-го отдела», и если «Зав.складом» отправляет им заявку от подразделения (заказчика), они привозят и отгружают товар «Подраздлению». Так же «Отдел инвентаризации» может провести инвентаризацию товарно-материальной ценности, но только в том случае если получит соответствующую заявку.

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

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

Логическое представление содержит:

1. диаграмма использования (рисунок 1);
2. диаграмму классов (рисунок 2);
3. диаграммы последовательности и кооперации (рисунок 3, 4);
4. диаграммы состояний (рисунок 5);
5. Диаграммы деятельности и компонентов (рисунок 6,7);
6. Диаграмма развертывания (рисунок 8).

На этой диаграмме показано взаимодействие классов, как и куда происходит перемещение и его учет.

Для лучшей наглядности были созданы следующие классы:

1. «Подразделение» (подразделение выполняет функцию клиента который заказывает у склада необходимое количество с помощью класса «АИС» (собственно «АИС» – это и есть олицетворение нашей разрабатываемой системы).

В него были включены следующие атрибуты: «Код подразделения» (для того чтобы сотрудники склада ориентировались кому и куда отправлять), «номер» (это номер который требуется заказать у сотрудников склада) и собственно «Телефон» (номер для обратной связи).

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

Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

Диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. [Приложение 1]

Базовыми отношениями между классами в языке UML являются:

• Отношение зависимости;
• Отчет – Admin, Пользователь, Товары, Склады
• База Данных – Admin, Пользователь, Товары, Склады
• Отношение ассоциации;
• Admin – Товары, Admin – Склады, Пользователь – Товары, Пользователь – Склады, Товары – Склады
• Отношение обобщения;
• Form – Отчет, Авторизация, MainForm, База Данных, Admin, Товары, Склады, Пользователь
• Отношение реализации.

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

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