Файл: Автоматизация учета расхода материалов на предприятии.pdf
Добавлен: 27.04.2023
Просмотров: 200
Скачиваний: 3
СОДЕРЖАНИЕ
1. Технико-экономическая характеристика предметной области и предприятия
1.1 Характеристика предприятия и его деятельности ООО «Gottlieb Care» была создана 18 апреля 2015г.
1.2 Организационная структура управления предприятием
2. Информационное обеспечение задачи
2.2 Характеристика нормативно-справочной, входной и результатной информации
2.3. Характеристика базы данных
Требования к ИС:
- Удовлетворение функциональным требованиям;
- ИС должна иметь приемлемую цену;
- Удовлетворять требованиям эксплуатации, характеристикам;
- Удовлетворять критериям дизайна;
- Удовлетворять требованиям к самому процессу.
|
Функция |
Сравниваемые системы |
|||
|
«МойСклад» |
«Фолио Купец» |
«Битрикс 24» |
||
|
Система автоматизации управления крупным складом |
+ |
+ |
+ |
|
|
Обработка заказов покупателей |
+ |
+ |
+ |
|
|
Объединение способов коммуникации с клиентом |
- |
+ |
+ |
|
|
Учет финансового оборота |
- |
+ |
+ |
|
|
Составление отчетности |
+ |
- |
+ |
|
|
Возможность интеграции с сайтом |
+ |
+ |
+ |
|
Таблица 5. Сравнение систем автоматизации.
1.4 Назначения и цели системы
Назначения системы:
1. Регистрация выполнения работ.
АСУ должна регистрировать процесс выполнения работ на каждой единице оборудования в режиме реального времени, буквально в два клика мышью компьютера.
Исполнитель должен видеть на экране компьютера свое задание на смену и все изменения в режиме реального времени. Нажатием одной кнопки обозначать начало и завершение работ по выбранной работе из предлагаемого списка, и указывать реально истраченное количество бумаги и других материалов на данную операцию, если оно отличается от автоматически рассчитанных данных.
2. Ведение базы данных клиентов, истории контактов.
АСУ должна содержать мощный CRM модуль для регистрации данных о заказчиках, вести учет заказов и просчетов работ каждого из них, сохранять всю историю контактов.
Необходим планировщик действий менеджеров, который позволит делать записи о планируемых контактах и сохранять их содержимое, напоминать о необходимых действиях в будущем и назначать такие «напоминалки» для себя и своих подчиненных в указанное время.
3. Расчет выработки сотрудников производственных цехов.
АСУ позволяет вводить данные по расчету сдельной премии сотрудников в соответствии с принятой на предприятии системой оплаты труда
АСУ должна собирать данные о допущенном браке, и помогать оценивать эффективность отдельных сотрудников или единиц оборудования. При обнаружении брака, должен быть механизм переделки этого заказа со списанием дополнительных материалов. С учетом этих данных могут назначаться штрафы и пересчитываться премии сотрудникам.
4. Товарно-материальный учет.
АСУ должна вести полный складской учет материалов и готовой продукции.
Должен быть реализован механизм закупки материалов по новым принятым заказам и впрок на склад, составления требований на получение или перемещение материалов с других участков типографий.
Должен быть реализован механизм ввода данных счетов поставщиков, приема товаров на склад, раскомплектовки и отдельного учета товаров, поставляемых в объемных упаковках, а расходуемых поштучно.
АСУ автоматически должен отслеживать список материалов по каждому рабочему заказу. Это позволит избежать ошибок при закупках и резервировании материалов, получать информацию о плановых и фактических затратах на материалы по каждому заказу.
Должны быть созданы разные механизмы списания материалов. Во-первых, расход материалов должен отражаться в режиме реального времени с привязкой к выполняемым заказам. Во-вторых, необходимо создать систему учета и списания материалов, которые невозможно отнести на конкретные заказы. Такие материалы должны накапливаться на складе «Отложка», и в конце месяца распределяться по всем выполненным за период заказам по различным методикам, наиболее подходящим к конкретному материалу.
5. Встроенная система сообщений.
АСУ должна иметь свой встроенный мессенджер (для обмена сообщений между сотрудниками без выхода из программы) и планировщик событий.
При наступлении событий, таких как: поступление на склад готовой продукции, поступление оплаты от клиента и пр., АСУП должен рассылать информационные сообщения списку адресатов, для которых это сообщение необходимо для работы.
Во встроенном планировщике сотрудники могут назначать события для напоминания себе или своим подчиненным в заданное время в будущем, связанное с общением с клиентами или выполнением какой-либо рабочей операцией в будущем.
Цели создания системы
Целями создания Системы являются:
- автоматизация процессов управления и контроля запасов;
- автоматизация процессов детального оперативного учета на складах;
- повышение производительности труда сотрудников.
Требования к системе:
Система должна обеспечивать достоверный и своевременный учет ТМЦ на складах вводом следующих документов:
- Поступление ТМЦ;
- Реализация ТМЦ;
- Перемещение ТМЦ;
- Внутреннее перемещение ТМЦ;
- Возврат из производства;
- Списание ТМЦ;
- Резервирование ТМЦ;
- Инвентаризация ТМЦ.
В базе данных Системы должны быть организованы следующие справочники:
- Склады (места хранения);
- Контрагенты (поставщики);
- Номенклатура;
- Подразделения;
- Список работников.
Системой должен быть предусмотрен механизм поиска документов (по дате, номеру документа), элементов справочников по ключевым характеристикам (код, наименование).
2. Информационное обеспечение задачи
2.1. Информационная модель

Рис. 5 Диаграмма деятельности.
2.2 Характеристика нормативно-справочной, входной и результатной информации
Рис. 6 Диаграмма прецедентов.
Описание прецедентов и актеров.
Актеры:
Администратор – человек, который занимается заполнением заявок на заказ у поставщика определенного вида материалов и непосредственно передачей этих заявок поставщику.
Поставщик – компания, состоящая из группы людей, которая после получения заявки, в течении нескольких суток отправляет нужный материал заказчику.
Зав. Складом – человек, принимающий материал от поставщика, контролирующий комплектацию заказа, а также занимается учетом поступления товара на склад.
Прецеденты:
Заказать материал – Инициируется администратором. Администратор заказывает все необходимое, для дальнейшего успешного производства.
Передать материал – Инициируется поставщиком. Поставщик привозит материал, который заказал администратор.
Рассчитаться за материал – Инициируется администратором. Поставщик привозит накладную на товар, администратор оплачивает товар по накладной, после проверки качества и состава товара.
Проверить комплектацию заказа – Инициируется зав. Складом. Заведующий складом проверяет комплектацию заказа, его состав и количество позиций всех товаров.
|
№ п/п |
Этап жизненного цикла |
Риски |
Снижение вероятности возникновения рисков |
|
1 |
Разработка требований |
Риск изменений требований |
Уточнить все детали заказчику. Помощь на всех этапах разработчику |
|
Неправильная трактовка требований |
Уточнение всех деталей разработчику. Перепроверка всех требований, повторное обсуждение. |
||
|
2 |
Проектирование |
Риски будущих сбоев системы |
Создание вспомогательных средств, обеспечивающих быстрое восстановление работоспособности системы |
|
3 |
Разработка |
Низкий уровень знаний команды разработчиков |
Точный, пунктуальный подбор команды разработчиков. |
|
4 |
Внедрение |
Риск непонимания новой системы сотрудниками |
Составление обучающих пособий, материалов, с точным описанием методов и принципов работы |
|
Неверный выбор стратегии внедрения |
Расставить приоритеты до начала разработки |
||
|
5 |
Эксплуатация и сопровождение |
Риски «подхватить» вирус |
Установка мощного антивируса |
|
Риск DDOS атак от конкурентов |
Установить профессиональную защиту от DDOS атак |
Таблица 6. Риски этапов ЖЦ и их возможное устранение.
|
№ п/п |
Этап жизненного цикла |
Возможные ошибки |
Последствия возникновения ошибки |
Пути снижения вероятности возникновения ошибки |
|
1 |
Разработка требований |
Неправильно подобраны системные требования |
Система не запустится или могут возникнуть фатальные поломки оборудования. |
Нанять грамотную команду татуировщиков, которые несколько раз проверят совместимость системных требований |
|
2 |
Проектирование |
Требования не полностью были поняты разработчиком |
Система не будет удовлетворять в полной мере |
Перепроверка всех требований, помощь разработчику на всех стадиях работы |
|
3 |
Разработка |
Ошибка в разработке кода |
Система будет постоянно выдавать ошибки, сбои |
Тщательная, неоднократная проверка кода |
|
4 |
Внедрение |
Риск потери информации |
Потеря важных файлов, документов |
Авто сохранение данных в определенный промежуток времени |
|
5 |
Эксплуатация и сопровождение |
Слабое обеспечение безопасности |
Вывод важных данных компании злоумышленниками |
Установить мощный антивирус или firewall |
Таблица 7. Возможные дефекты программного продукта.
2.3. Характеристика базы данных
Рис. 7 Схема данных
Описание таблиц
Таблица 1 «Заказы»
|
Наименование поля |
Идентификатор поля |
Тип поля |
|
Номер заказа |
Ключ |
Счетчик |
|
Заказчик |
- |
Подстановка |
|
Дата заказа |
- |
Дата и время |
|
Дата выдачи |
- |
Дата и время |
|
Статус заказа |
- |
Подстановка |
|
Принял заказ |
- |
Числовой |
Таблица 2 «Клиенты»
|
Наименование поля |
Идентификатор поля |
Тип поля |
|
Код клиента |
Ключ |
Счетчик |
|
ФИО клиента |
- |
Короткий текст |
|
Номер телефона |
- |
Короткий текст |
|
Скидка клиента |
- |
Подстановка |
Таблица 3 «Материал»
|
Наименование поля |
Идентификатор поля |
Тип поля |
|
Код материала |
Ключ |
Счетчик |
|
Наименование |
- |
Короткий текст |
|
Количество |
- |
Числовой |
|
Поставщик |
- |
Подстановка |
Таблица 4 «Поставщики»
|
Наименование поля |
Идентификатор поля |
Тип поля |
|
Код поставщика |
Ключ |
Счетчик |
|
Наименование поставщика |
- |
Короткий текст |
|
Скидка |
- |
Подстановка |