Содержание

Введение

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

1.1 Обзор деятельности фирмы ЗАО «Поликомм»

1.2 Обзор и анализ области внедрения

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

1.4 Достоинства и недостатки существующих АСУ

1.5 Постановка задачи на разработку автоматизированной системы

1.5.1 Назначение

1.5.2 Функциональные требования

1.5.3 Требования к надежности

1.5.4 Требования к аппаратным средствам

1.5.5 Требования к информационно-программной совместимости

1.5.6 Требования к программной документации

Глава 2. Проектирование автоматизированной системы торговой деятельности

2.1 Принципиальное проектное решение

2.1.1 Выбор архитектуры программного обеспечения

2.1.2 Выбор программной среды для создания информационной системы.

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

2.2 Структурный анализ точек функциональности

2.3 Проектирование структуры программного обеспечения.

2.4 Проектирование информационного обеспечения

2.5 Проектирование структуры БД

2.6 Проектирование приложения “Прайс”.

2.7 Проектирование приложения “Счета”.

2.8 Проектирование приложения “Склад”.

2.9 Проектирование приложения “Заказы”

Глава 3. Экспериментальная проверка программного комплекса

3.1 Исходные данные и постановка задачи для проведения тестирования.

3.2 Тестирование приложений

3.3 Анализ результатов, полученных при тестировании

Глава 4. Расчет экономической эффективности проекта

4.1. Анализ рыночных возможностей продукта.

4.2. Расчет единовременных затрат на разработку ПО.

4.3. Единовременные расходы организации заказчика ПО при внедрении автоматизированных рабочих мест (АРМ)

Стоимость ЭВМ, прочих аппаратных средств и сетевого оборудования

ПК

4.4. Источники финансирования проекта.

4.5. Текущие расходы пользователя ПО при эксплуатации АРМ.

4.6. Экономия текущих затрат пользователя ПО.

4.7 Показатели экономической эффективности проекта.

Выводы по главе.

Заключение

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

Введение

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

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

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

Обзор и анализ существующих автоматизированных систем управления

Определение категорий пользователей системы

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

Определение требований к аппаратному обеспечению, информационно-программной совместимости и программной документации

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

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

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

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

Во-первых, это конечно относительно низкая стоимость такой разработки.

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

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

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

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

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

1.1 Обзор деятельности фирмы ЗАО «Поликомм»

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

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

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

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

Основными сферами деятельности предприятия являются:

Проектирование и внедрение сетевых проектов автоматизации масштаба предприятия

Комплексное решение задач включения предприятий в сеть Интернет.

Совместно с компанией "S-Energy" фирма участвовала в программах комплексного включения организаций и фирм во всемирную сеть Internet. Вот самые крупнейшие из них, работающие на сетевом и офисном оборудовании от "Polycomm" и пользующиеся услугами интернет-провайдера "S-Energy":

- БелГУ

- Областное УВД

- ЮКОС (Белнефтепродукт)

- Белдорбанк

- ОАО "Белгородэнерго"

- Администрация БО

- БМК

- БелГТАСМ

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

- Православная гимназия

- Белгородско-Старооскольская епархия

- Новооскольская церковно-приходская школа

- Средняя школа п. Уразово (Валуйского района)

- Гимназия № 1 г. Валуйки

- Казинская с.ш.

- Казначеевская с.ш.

- Колосковская с.ш.

- Бутырская с.ш.

- Губкинская с.ш. №4 и №9 г.Губкин

Установка телефонных сетей

Цифровая АТС Lucent Definity максимальной емкостью 2400 абонентов, обслуживающая более 500 телефонов в зданиях нового комплекса БелГУ, учережденческая АТС Samsung DCS департамента автодорог общего пользования администрации Белгородской области, обслуживающая порядка 130 абонентов. учережденческие АТС отделений пенсионного фонда Белгородской области (9 районов), более 20 офисных мини АТС.

Создание репрографических центров предприятия

Производство и продажа компьютеров под собственной торговой маркой "Polycomm".

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

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

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

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

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

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

Компания имеет лицензию на строительство зданий и сооружений I и II уровней ответственности в соответствии с Государственным стандартом.

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

Сертификат участника маркетинговых программ Intel - гарантия обеспечения технической поддержки компании и регулярного обучения специалистов.

Диплом и статуэтка лучшего дилера компании OCS-Юг южного региона России по итогам 2003-2004 г.

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

1.2 Обзор и анализ области внедрения

На данный момент в России формируется рынок крупных проектов в сфере информационных технологий, затрагивающих не одно предприятие, а целые отрасли. По мнению экспертов компании “Оптима” [4], потенциальных заказчиков в ИТ – сфере на российском рынке целесообразно разбить на несколько групп:

Передовые (топливно-энергетический комплекс);

Перспективные (металлургия, банковский и финансовый сектор, госсектор);

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

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

Перспективные. Как полагают аналитики «Оптимы», значительный потенциал в области автоматизации у металлургической отрасли. Передел собственности в ней близок к завершению, и на первый план выходят вопросы эффективности управления финансами и производством. Многие металлургические комбинаты переходят или планируют перейти на производство под заказ, что требует внедрения полноценных систем планирования и учета. Свободные средства у металлургических холдингов есть, а средний уровень автоматизации предприятий отрасли невысокий. На закупку и внедрение ИТ-решений металлургические предприятия выделяют не более 0,5% от оборота компании; средние и того ниже – около 0,1%. Вместе с тем руководители передовых предприятий считают, что расходы на ИТ необходимо увеличить до 0,7% - 1,5% от оборота. Так что металлургические холдинги становятся многообещающими потребителями информационных технологий.

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

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

Достичь требуемой безопасности производства и преемственности технологий;

Создать надежную коммуникационную среду (на решение этой задачи направляется сейчас до 75% всех вложений отрасли в ИТ);

Повысить эффективность производства.

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

Другая весьма перспективная отрасль для внедрения ИТ – банковский и финансовый сектор. Многие банки переосмысливают сейчас стратегию бизнеса и свое место на рынке. Корпоративные клиенты давно поделены и конкуренция в банковском секторе очень высокая. Наиболее доходными и устойчивыми оказываются банки, предоставляющие максимально широкий спектр финансовых услуг. И многие банки стремятся перейти из разряда специализированных в универсальные. А стремление к универсальности и расширению клиентуры требует внедрения новых информационных технологий, особенно на базе Интернета. На закупку и внедрение информационных технологий банки выделяют не менее 5% годовой сметы расходов.

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

Растущие. Торговые розничные сети и производители потребительских товаров представляют собой звенья одной производственно-коммерческой цепи. Эти отрасли динамично развиваются. За счет строительства новых заводов, фабрик и магазинов в них появляется много новых объектов для автоматизации. Особенно актуальным является внедрение информационных технологий в крупных торговых домах. Расходы торговых домов на информационные технологии растут и сейчас достигают 0,5 – 1% торгового оборота.

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

Первые автоматизированные системы управления ресурсами предприятия основывались на расчетах по спецификации состава изделия. По плану выпуска изделий формировались планы производства и рассчитывались объемы закупки материалов и комплектующих изделий /АПИК92/. Конец 60-х годов связан с работами Оливера Уайта /Уайт78/, который в условиях автоматизации промышленных предприятий предлагал рассматривать в комплексе производственные, снабженческие и сбытовые подразделения. Такой подход и применение вычислительной техники впервые позволили оперативно корректировать плановые задания в процессе производства (при изменении потребностей, корректировке заказов, отказах оборудования). В публикациях Уайта и Американского общества по управлению запасами и производством /АР92/ были сформулированы алгоритмы планирования, сегодня известные как MRP (Material Requirement Planning) – планирование потребностей в материалах. Однако у концепции MRP есть серьезный недостаток. При расчете в рамках этой концепции потребности в материалах не учитываются ни имеющиеся производственные мощности, ни их загрузка, ни стоимость рабочей силы. Этот недостаток был исправлен в концепции MRPII (Manufacturing Resource Planning – планирование производственных ресурсов) MRPII позволяла учитывать и планировать все производственные ресурсы предприятия – сырье, материалы, оборудование, персонал, и т.д.

По мере развития концепции MRPII к ней добавлялись возможности учета остальных затрат предприятия. Так появилась концепция ERP (Enterprise Resource planning – планирование ресурсов предприятия). В основе ERP лежит принцип создания единого хранилища данных, содержащего всю деловую информацию, накопленную организацией в ходе ведения бизнеса. Наличие хранилища (репозитария) избавляет от необходимости передавать данные от приложения к приложению, кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями.

Системы ERP предназначены для управления финансовой и хозяйственной деятельностью предприятий. Это «верхний уровень» в иерархии систем управления предприятием, затрагивающий ключевые аспекты его производственной и коммерческой деятельности, такие как производство, планирование, финансы и бухгалтерия, материально-техническое снабжение и управление кадрами, сбыт, управление запасами, ведение заказов на изготовление продукции и предоставление услуг. Такие системы создаются для предоставления руководству информации для принятия управленческих решений, а также для создания инфраструктуры электронного обмена данными предприятия с поставщиками и потребителями [5]. Концепция ERP нашла широкое применение, поскольку планирование ресурсов позволяло сократить время выпуска продукции, снизить уровень товарно-материальных запасов, а также улучшить обратную связь с потребителями при одновременном сокращении управленческого аппарата.

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

В настоящее время все западные системы управления производством базируются на концепции ERP и отвечают ее рекомендациям. К сожалению, по мнению Б. Гайфулина [6], большинство современных российских систем управления производством, не отвечают даже требованиям MRP, не говоря уже о других, более сложных концепциях.

Самый новый из стандартов управления предприятиями – CSRP (Customer Synchronized Resource Planning) – помимо всего прочего охватывает и взаимодействие с клиентами, оформление нарядов – заказов и технических заданий, поддержка заказчика на местах и т.д. Суть концепции CSRP состоит в том, чтобы интегрировать заказчика в систему управления предприятием.

По данным агентства Beafnd [6] на мировом рынке сейчас предлагается свыше 500 систем класса MRPII – ERP. Развитие этого рынка идет очень быстрыми темпами – число внедрений таких систем в мире растет на 35-40% в год. На отечественном же рынке присутствует около десятка западных и три – четыре отечественные системы класса КИС (корпоративные информационные системы). Все они представлены в таблице 1. Представленные в таблице системы отличаются от других присутствующих на российском рынке программных продуктов для автоматизации финансово-хозяйственной деятельности наиболее развитой функциональностью, а также тем, что в них имеется модуль планирования производства и оперативного управления им.

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

Таблица 1.1. Российские и западные ERP-системы, представленные на отечественном рынке

Наименование продукта	Фирма-производитель	Краткое описание
R/3	SAP AG www.sap.com	SAP -- безусловный лидер по объемам продаж ПО данного класса в России. Компания держит порядка 40% всего российского рынка ERP-систем. Система R/3 относится к классу крупных интегрированных систем и имеет в своем составе модули, которые существенно расширяют рамки традиционной ERP-системы. Стоимость решения на 50 рабочих мест составляет ориентировочно около $350 тыс. Стоимость внедрения как минимум равна стоимости лицензий, а чаще всего в несколько раз превышает ее. Срок внедрения зависит от требуемых функциональных возможностей. Можно сказать, что для российских предприятий он в среднем составляет год-два. Один из наиболее полномасштабных проектов внедрения системы R/3 осуществлен на Омском нефтеперерабатывающем заводе.
Oracle Applications	Oracle www.oracle.ru	Позиции компании Oracle в России существенно слабее, чем у ее основного конкурента. Однако в мире в рейтинге Top100 журнала Manufacturing Systems за 2000 год система Oracle Applications обошла по финансовым показателям R/3 и заняла первое место. Отставание в России можно объяснить отчасти тем, что данное решение значительно позднее вышло на отечественный рынок. Стоимость решения на базе Oracle Applications несколько ниже, чем на базе R/3 (конкретных цифр в открытой печати не приводилось). Срок внедрения у
		Oracle Applications и R/3 примерно одинаков. Из наиболее известных проектов внедрения Oracle Applications можно отметить реализованный на Магнитогорском металлургическом комбинате.
Baan IV	Baan www.baan.ru	Еще одна из западных ERP-систем, присутствующих на российском рынке. Класс системы тот же, что и у двух предыдущих. Стоимость именованной лицензии (на одного конкретного пользователя) составляет $3000, стоимость конкурентной лицензии (вне зависимости от количества сотрудников указывает только на ограничения по одновременному подключению к базе данных) -- $6000. Внедрение в России в 1--3 раза дороже стоимости лицензий. Пример реализации - "Нижфарм". К сожалению, в России в настоящее время активно продвигается устаревшая версия системы, несмотря на то, что уже давно появилась версия iBaanERP.
Irenaissance	ROSS Systems www.rossinc.com	Система ERP-класса для предприятий с процессным (непрерывным) типом производства. Полностью локализована, успешно внедряется в России с 1998 г. В мире - 3500 законченных внедрений, есть внедрения в России (Mary Kay, Alcoa CSI Vostok и др.). Невысокая стоимость и сроки внедрения.
SyteLine	SYMIX www.frontstep.ru	Данная система относится к классу средних интегрированных систем. Имеет довольно много внедрений на предприятиях пищевой промышленности России. В их числе можно назвать Воронежскую кондитерскую фабрику.
Axapta	Damgaard Data Int.	Система класса ERP, предназначенная для автоматизации средних и крупных производственных и торговых
	www.damgaard.ru	предприятий. Это первая ERP-система, полностью ориентированная для работы в Интернете. Пример внедрения системы - холдинг "РУССО (Русские сорочки)". Общее количество установленных рабочих мест - 30. Стоимость внедрения ориентировочно может составлять несколько сот тысяч долларов.
MFG/PRO*	QAD www.qad.com	ERP-система для крупных и средних предприятий с дискретным типом производства. 5200 законченных внедрений в мире, 8 - в России. Полностью локализована. По мнению различных экспертов, система является одним из самых сильных решений для дискретных производств (машиностроение, легкая промышленность, автомобилестроение, электроника и т.д.).*
"ПАРУС"	Корпорация "Парус" www.parus.ru	Относится к классу финансово-управленческих систем. С точки зрения производства имеет возможности учета и простейшего планирования. Традиционно очень сильны позиции корпорации в бюджетных организациях.
"Галактика"	Корпорация "Галактика" www.galaktika.ru	Данная система является лидером среди российских систем управления предприятием. По отдельным оценкам, ее доля составляет около 40% от всех российских поставщиков. По объемам продаж система уступает только R/3.Срок внедрения сильно зависит от выбранной функциональности и масштабов предприятия. Например, внедрение 100 рабочих мест на ОАО "Русский продукт" заняло около полутора лет.
"БОСС-Корпорация"	Компания "АйТи" www.it.ru	Интеграция учетных функций с производственной системой позволит данному продукту ускорить переход к классу средних интегрированных систем. Из наиболее успешных проектов отмечается проект по созданию
		системы управления финансами на Красноярском алюминиевом заводе.
"1С: Торговля и склад"	Компания1С www.1c.ru	Хотя продукция компании 1С относится к классу локальных систем, не отметить данного игрока нельзя. В своем классе 1С занимает лидирующее положение, далеко опережая конкурентов. В составе продукции 1С есть и система "1С: Торговля и склад ", которая позволяет в некотором объеме решить задачи производственного учета.

1.4 Достоинства и недостатки существующих АСУ

Рассмотрим некоторые критерии, учитываемые при оценке существующих систем. Масштабируемость – речь идет о способности системы наращивать свой размер, как за счет увеличения числа функций, так и за счет увеличения круга пользователей. Адаптация к российским условиям – необходимо отметить, что этот критерий играет большую роль при внедрении автоматизированной системы. Он предполагает наличие механизмов проведения операций, в соответствии с существующим законодательством РФ, стандартизованных форм отчетности и т.д. Под программной совместимостью понимается способность программного продукта к совместному использованию с наиболее распространенными платформами, системами управления базами данных, средствами сторонних разработчиков. Критерий “Аналитика” определяет степень наличия аналитических функций и логистики в продукте.

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

Таблица 1.2.

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

	Стоимость	Надежность	Срок внедрения	Масштаби-руемость	Адаптация к российским условиям	Программ-мная совмести-мость	Аналитика	Аппаратные требования
R/3	-	+	-	+	-	-	+	-
Oracle Applications	-	+	-	+	-	-	+	-
Baan IV	-	+	-	-	-	-	+	-
Axapta	+	-	-	+	-	+	+	-
MFG/PRO	-	+	-	+	-	+	+	-
Style Line	-	-	+	-	-	+	-	+
Irenaissance	-	-	+	-	-	+	-	-
“Парус”	+	-	-	-	+	+	-	+
“Галактика”	+	-	+	-	+	-	+	+
"БОСС-Корпорация"	-	-	-	+	+	-	-	-
1C”Торговля и склад”	+	-	+	-	+	-	-	+

Проанализировав эту таблицу, можно сказать, что использование зарубежных продуктов, имеющих отличную репутацию, таких как R/3 и Oracle Applications обойдется совсем недешево. Они смогут предложить развертывание полномасштабных надежных автоматизированных систем управления, с мощными аналитическими функциями, но не для российского предприятия. Адаптация к условиям отечественного рынка потребует огромных затрат, да и решения эти все еще слишком требовательны к аппаратным требованиям. На другом полюсе – относительно недорогие решения отечественных производителей программного обеспечения: 1C”Торговля и склад”, “Галактика”, “Парус” и "БОСС-Корпорация". Сразу отметим, что достойные аналитические функции предоставляет только продукт “Галактика”, а требованиям к надежности не удовлетворяет ни одна из этих марок. Baan IV, Axapta, MFG/PRO, Style Line, Irenaissance – “золотая середина”. К сожалению только Axapta и MFG/PRO имеют пятидесятипроцентное соотношение достоинств и недостатков. Мы не ставим задачу выбора лучшей из них, а говорим о том, почему же необходимо новое решение.

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

1.5 Постановка задачи на разработку автоматизированной системы

1.5.1 Назначение

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

1.5.2 Функциональные требования

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

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

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

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

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

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

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

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

1.5.3 Требования к надежности

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

1.5.4 Требования к аппаратным средствам

Требования к аппаратному обеспечению автоматизированной системы управления торговой деятельностью предприятия вытекают из текущего состояния технической оснащенности предприятий, поэтому, на сегодняшний день, эти требования не должны быть очень высокими. Минимальные требования к компьютеру для работы с автоматизированной системой – Intel Pentium I 200MHz, 32Mb ОЗУ. Обязательным условием является наличие локальной сети Ethernet спецификации IEEE 802.3(10 Мбит/с) или выше и оборудования для обеспечения ее функционирования. Требования к топологии сети отсутствуют.

1.5.5 Требования к информационно-программной совместимости

Требования к программной совместимости: возможность внедрения на платформе Windows 2000 Server; поддержка работы с СУБД Oracle 8i; возможность подключения автоматизированной системы управления торговой деятельностью предприятия как модуля для любой ERP-системы;

В процессе эксплуатации программного продукта, зачастую возникают задачи, которые невозможно решить внутренними средствами. Интеграция средств сторонних разработчиков для решения этих задач приводит к значительному увеличению цены разработки. Поэтому автоматизированная система должна иметь интерфейсы для обмена информацией с наиболее распространенными приложениями для хранения и обработки информации: MSWord, MSExcel. Должна быть реализована поддержка программных средств сторонних производителей: FastReport, ExcelReport.

1.5.6 Требования к программной документации

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

Глава 2. Проектирование автоматизированной системы торговой деятельности

2.1 Принципиальное проектное решение

В качестве автоматизированной системы управления торговой деятельностью предприятия предлагается использовать многопользовательское клиент-серверное приложение(двухуровневая архитектура), разработанное с помощью интегрированной среды Borland Delphi 7 Enterprise Edition. В качестве системы управления базами данных предполагается использование продукта Oracle 8i Enterprise, на базе которого будет развернута комбинированная OLAP\OLTP информационная система, где OLAP-компонента(Online Analytical Process) – обеспечит аналитические функции работы системы(небольшое число запросов, время отклика некритично)

OLTP-компонента (Online Transaction Process) – обеспечит функции оперативного доступа большого числа клиентов(большое число запросов, минимальное время отклика)

Информационная система будет развернута на основе операционной системы Windows 2000 Server платформы Intel. Аппаратная часть: сервер - минимальные требования к конфигурации Intel Pentium-3 450 MHz, 128 Mb ОЗУ. Рекомендуемая конфигурация - Intel Pentium-4 2,4 GHz, 512 Mb ОЗУ. В качестве операционной системы клиентской части предполагается использовать Windows 98 и выше, поэтому требования к аппаратному обеспечению таковы: минимальные – Intel Pentium-2MMX 200MHz, 32Mb ОЗУ. Рекомендуемые - Intel Pentium-3 450 MHz, 128 Mb ОЗУ.

2.1.1 Выбор архитектуры программного обеспечения

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

Рис.1 Архитектура информационной системы

Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей - автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого выступает Oracle. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть может быть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает недостатками, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе. Поэтому я решила отступить от классического варианта “толстого” клиента и постарался максимально переместить бизнес-логику на сервер, тем самым снизив требования к аппаратному обеспечению клиента и пропускной способности сети. Логика работы системы реализована в виде пакетов хранимых процедур, каждый из вместе с триггерами таблиц которых реализует функционал одного из модулей системы. Таким образом на клиентскую машину будут передаваться не данные для обработки, а обработанные данные.

2.1.2 Выбор программной среды для создания информационной системы

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

Oracle Developer.

Borland Delphi 5-8.

Borland C++ Builder 4-6

Microsoft Visual Studio 6.0

Microsoft Visual Studio .Net

При разработке информационной системы с использованием СУБД Oracle, было бы вполне логично остановиться на первом – “родном” варианте этой компании. В пользу этого варианта говорит и то, что в пакете представлены профессиональные CASE-средства для моделирования и анализа бизнес-процессов(Oracle Designer) с последующей генерацией скриптов для создания базы данных и автоматического формирования макета приложения в соответствии с моделью автоматизированной системы(Oracle Forms), наличие средств генерации отчетов(Oracle Reports) и работы с графикой(Oracle Graphics). Однако, при более детальном изучении этих продуктов становиться ясно, что их использование приведет, во-первых к жесткой привязке программного продукта к политике лицензирования компании Oracle(что на деле выливается в значительные финансовые вложения), а, во-вторых, поскольку это средства с закрытым программным кодом, к уменьшению гибкости приложения. Встает проблема информационной совместимости с другими программными продуктами. Переход компании Oracle к ориентации на средства Java-разработки для приложений работающих в гетерогенных средах, вылился в отказ от поддержки и развития этого пакета. Становится ясно, что этот продукт не подходит для разработки нашей информационной системы.

Borland Delphi 8 for .Net Architect Edition и Microsoft Visual Studio .Net я решила не использовать из-за их сильной ориентации на платформу .NET. Хотя они и позволяют разрабатывать обычные приложения с использованием библиотек WinForms и VCL, для нашей задачи они сильно перегружены средствами для этой платформы.

Я остановила свой выбор на среде Delphi 7 Enterprise Edition. И вот почему:

Ориентация на разработку Win32-приложений

Самые развитые(на мой взгляд) средства для разработки приложений баз данных

Наличие 4 альтернативных интерфейсов работы с СУБД Oracle: ODBC, ODAC, DOA, CLI.

Компонентная технология и необычайно быстрый компилятор [8]

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

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

В предыдущих пунктах часто упоминалось, что основным инструментом для полного контроля над данными будет выступать СУБД Oracle 8i. Стоит отметить, что по экспертным оценкам собственные разработки автоматизированных систем управления в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД. Я остановилась на этом решении по следующим соображениям:

На первом месте конечно же стоят требования к объемам данных с которыми предстоит работать. Поскольку речь идет о масштабируемой системе управления предприятием крупного бизнеса, то, очевидно, что только документооборот предполагает обработку миллионов записей ежегодно. Для примера, размер корпоративной информационной системы Омского нефтеперерабатывающего завода в год увеличивается на миллионы записей. Сервер Oracle 8i, традиционно ориентирован на работу с очень большими объемами информации [7]. MSSQLServer 2000, Interbase-Firebird-Yaffil, mySQL не предназначены для работы с такими информационными массивами.

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

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

2.2 Структурный анализ точек функциональности

Здесь немного про RAD.

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

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

Рис.2 Контекстная диаграмма потоков данных

Анализ функциональных требований показывает, что система управления должна иметь возможность взаимодействия с поставщиками товаров, что отражено на диаграмме двумя потоками данных с внешней сущностью “Distributor” (Поставщик). Первый из них определяет список товаров и услуг, которые необходимо получить у поставщика(“Заказы”), а второй несет информацию о фактически полученных товарах(“Поставки”). Связи с внешней сущностью “Клиент” осуществляют:

поток данных, отвечающий за предоставление входной информации о требованиях клиента(“Список товаров”)

поток данных выходной информации о предоставленных клиенту товарах и услугах

Взаимодействие с внешней сущностью (“Бухгалтерия”) осуществляется за счет выгрузки сведений о продажах потоком данных “Книга продаж”. Подтверждение безналичных платежей от внешней сущности “Банк” выполняет поток данных (“Платежи”).

2. Диаграмма потоков – детализация контекстной диаграммы. Она представляет собой множество процессов и хранилищ данных, объединенных потоками данных, что позволяет отобразить структуру функционирования информационной системы. Процесс “Сформировать склад” на основе внешнего потока данных “Поставки” формирует хранилище данных “Склад”. Таким образом, склад товаров формируется не из отдельных товаров, а из их групп – поставок, что позволяет точно определить дату прибытия и поставщика товара, а также контролировать не только состояние склада, но и процесс работы с поставщиками. На основании данных этого хранилища, формируется выходной документ – “Счет-фактура” (“Чек”), отражающий реальный отпуск товаров по позициям счета. Процесс “Получить прайс” выполняет обработку хранилища данных “Склад” для формирования прайс-листа товаров на текущий момент. Обработка заключается в определении наличия каждого товара на складе, подсчете количества товара, определении количества свободных и зарезервированных по счетам товаров, преобразовании входных цен в выходные, поддержке мультивалютной системы расчетов (конвертации цен). Результатом этого процесса является хранилище данных “Прайс”. Именно с его помощью, входной поток данных “Список товаров и услуг” от клиента преобразуется в счет – одну из основных сущностей информационной системы. Процесс “Сформировать счет” на основании требований клиента и информации хранилища “Прайс” получает счет клиента, который заносится в хранилище данных – “Счета”. По окончании расчетного периода (месяц) из него происходит выгрузка данных в бухгалтерию потоком данных “Книга продаж”. На основе списка выписанных счетов происходит формирование заказов – процесс “Сформировать заказ” для заполнения хранилища данных “Заказы”. Этот процесс автоматически формирует список закупок, которые после корректировки поставщика и количества товаров образуют выходной поток данных “Заказы”.

Рис.3 Диаграмма потоков данных первого уровня

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

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

Для работы со складом

Для работы с прайс-листом

Для работы со счетами

Для работы с заказами

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

Для формирования наборов данных при работе со складом

Для удобной работы с прайс-листом и группами товаров

Для работы с группами счетов

Для автоматической генерации заказов.

2.3 Проектирование структуры программного обеспечения

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

Рис.4 Связь приложений программного комплекса

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

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

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

Приложение “Заказы”. Предназначено для формирования плана закупок по счетам, возможности редактирования заказов, работы с поставщиками, формирования выходных документов – списков заказов(плана закупок) и аналитических отчетов по закупкам в разрезе поставщиков и отчетных периодов. Пользователи – менеджеры по закупкам.

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

2.4 Проектирование информационного обеспечения

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

Рис.5 ER-модель информационной системы

На рисунке 5 изображены основные сущности информационной системы и их атрибуты. Сущность “Счет” имеет ключевой атрибут “Номер” и связан с сущностью “Клиент” отношением многие – к - одному (атрибут “Клиент”). Она отражает абстрактный объект – счет клиента, с его свойствами: суммой счета и датой выписки. Атрибут состояние отражает текущее состояние счета: “Выписан”, “Оплачен”, “Выполнен”. Сущность “Клиент” отражает реальный объект – покупателя, то есть физическое или юридическое лицо (определяется атрибутом “Тип”) и его реквизиты: для физического лица – Ф.И.О., для юридического лица – “Имя”, “Расчетный счет”, ”ИНН”, “Телефон” и “Ф.И.О. руководителя”. Сущность “Книга продаж” представляет собой список счетов за период. Сущность “Товар” – одна из основных сущностей системы отражает реальный объект – товар с атрибутами “Наименование” и “Входная цена”. “Счет” связан с этой “Сущностью” отношением один -ко- многим. Сущность “Прайс” описывает свойства абстрактного объекта прайс-лист и связана отношением один – ко - многим с сущностью “Товар”. Для формирования сущности “Заказ” необходима его связь с сущностью “Счет” отношением один-ко- многим с сущностью “Счет”. Реальный объект – поставщик определяется с помощью одноименной сущности с атрибутами, отражающими реквизиты организации-поставщика. Так как поставщик может одновременно выполнять несколько заказов, то соответствующая ему сущность связана с сущностью “Заказ” отношением один -ко- многим. Сущность “Поставка” описывает абстрактный объект – поставку, которая имеет свойства(атрибуты) “Дата” и “Поставщик”. Таким образом сущность “Склад” состоит из абстрактных объектов-поставок, которые состоят из реальных объектов – товаров. Необязательная связь между сущностью “Склад” и сущностью “Товары” отражает альтернативный способ пополнения склада – вне поставок.

2.5 Проектирование структуры БД

Таблица “Товар”.

Назначение: Хранение информации о товарах.

Поля:

Номер – уникальный номер товара в таблице

Наименование – наименование товара

Входная цена, USD – текущая входная цена товара

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

Группа – ссылка на группу товара.

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_NUM реализует связь один-ко-многим по полю “Номер”. С ее помощью можно представить реляционную таблицу в виде дерева.

Рис.5 Структура базы данных.

Таблица “Книга продаж”

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

Поля:

Номер – уникальный номер товара в таблице

Номер счета – ссылка на счет, которому принадлежит данный товар

Количество товара –количество единиц товара

Номер товара– ссылка на товар

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Товар реализует связь один-ко-многим по полю “Номер” с таблицей “Товар”.

Таблица “Счет”

Назначение: хранение списка счетов клиентов.

Поля:

Номер – уникальный номер счета в таблице

Клиент – ссылка на клиента, которому счет выписан счет

Дата – дата выписки счета

Сумма – суммарная стоимость товаров, включенных в счет

Состояние – “выписан”, “оплачен”,”выполнен”

Скидка – скидка по счету

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Клиент реализует связь многие-к-одному по полю “клиент” с таблицей “Клиент”.

Таблица “Клиент”

Назначение: хранение списка клиентов.

Поля:

Номер – уникальный номер клиента таблице

Тип – признак физического или юридического лица

ФИО\Наименование - ФИО\Наименование клиента

Телефон - телефон юридического лица

Адрес – адрес юридического лица

Р\С – расчетный счет юридического лица

ИНН – Индивидуальный номер налогоплательщика

Директор – директор организации-клиента

Гл. бухгалтер - гл. бухгалтер организации-клиента

Первичный ключ: Содержит поле “Номер”

Внешние ключи: отсутствуют

Таблица “Заказ”

Назначение: используется для хранения списка заказов

Поля:

Номер – уникальный номер заказа в таблице

Дата – Дата формирования заказа

Поставщик – ссылка на поставщика, которому будет передан заказ

Сумма – суммарная стоимость заказа в ценах поставщика

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Поставщик реализует связь один-ко-многим по полю “Поставщик” с таблицей “Поставщик”.

Таблица “Содержимое заказа”

Назначение: предназначена для хранения списка товаров (ссылок), которые вошли в заказы.

Поля:

Номер – уникальный номер товара в таблице

Номер товара – ссылка на товар

Количество товара – количество единиц товара

Входная цена – цена на товар в момент заказа

Номер заказа – ссылка на заказ, которому принадлежит товар

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Заказ реализует связь один-ко-многим по полю “Номер заказа” с таблицей “Заказ”.

Таблица “Поставка”

Назначение: хранение списка поставок.

Поля:

Номер – уникальный номер поставки в таблице

Дата прихода поставки на склад

Номер поставщика – ссылка на поставщика

Сумма – суммарная стоимость товаров в поставке

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Поставщик реализует связь один-ко-многим по полю “Номер поставщика” с таблицей “Поставщик”.

Таблица “Поставщик”

Назначение: хранение информации о поставщиках

Поля:

Номер – уникальный номер поставщика в таблице

Наименование - наименование поставщика

Телефон – телефон поставщика

Адрес – адрес поставщика

Р\С – расчетный счет поставщика

ИНН – Индивидуальный номер налогоплательщика

Контактное лицо – контактное лицо

Первичный ключ: Содержит поле “Номер”

Внешние ключи: отсутствует

Таблица “Содержимое поставки”

Назначение: хранение информации о списке товаров по каждой поставке

Поля:

Номер – уникальный номер товара в таблице

Номер поставки – ссылка на поставку

Количество товара – количество единиц товара

Номер товара – ссылка на товар

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Поставка реализует связь один-ко-многим по полю “Номер поставки” с таблицей “Поставка”.

Таблица “Банк”

Назначение: хранение списка банков, с которыми работает организация

Поля:

Номер – уникальный номер банка в таблице

Наименование - наименование банка

Номер вх. счета - номер счета входящих платежей

Номер исх. счета - номер счета исходящих платежей

Телефон – телефон

Первичный ключ: Содержит поле “Номер”

Внешние ключи: отсутствует

Таблица “Платеж”

Назначение: хранение реестра входящих и исходящих платежей.

Поля:

Номер – уникальный номер платежа в таблице

Сумма – сумма платежа

Банк – ссылка на банк

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

Дата - дата платежа

Тип – входящий\исходящий

Описание – для пользователя

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Банк реализует связь один-ко-многим по полю “Банк” с таблицей “Банк”.

Таблица “Счет-фактура”

Назначение: хранение списка счет-фактур

Поля:

Номер – уникальный номер счет-фактуры в таблице

Дата формирования

Номер поставщика – ссылка на поставщика

Сумма – суммарная стоимость товаров в поставке

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Поставщик реализует связь один-ко-многим по полю “Номер поставщика” с таблицей “Поставщик”.

2.6 Проектирование приложения “Прайс”

В этом приложении, в качестве структуры данных для хранения товаров было выбрано дерево. Физически, дерево представляет собой реляционную таблицу с дополнительным полем ”Родитель”, которое позволяет организовать связь между группами \ подгруппами и товарами. Первый узел - “Все товары” не имеет родителя и все группы или товары первого уровня являются его потомками. Как следует из анализа требований приложение “Прайс” должно выполнять определенные функции, вызов которых осуществляется из главного меню приложения (рис. 6).

Рис.6 Приложение “Прайс” – главная форма.

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

Товары

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

Удаление. Позволяет удалить товар из прайс-листа. Не влечет за собой изменения склада\поставок. Отражает факт прекращения работы с данным товаром. Входная информация: товар(номер). Выходная информация – измененный прайс-лист.

Редактирование свойств товара. Позволяет изменить входную цену и наименование товара. Входная информация: Наименование и цена товара. Выходная информация – измененный прайс-лист.

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

Группы товаров

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

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

Редактирование группы. Позволяет изменить наименование группы. Входная информация: Наименование группы. Выходная информация – измененный прайс-лист.

Другие

Выгрузить группу товаров. Позволяет получить *.xls или *.rtf файл с содержимым активной группы товаров или распечатать эту информацию без сохранения. Входная информация: Группа. Выходная информация – *.xls или *.rtf файл или его печатная копия.

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

Для более детального описания приложения рассмотрим его UML-диаграмму, представленную на рисунке 7.

Рис.7 UML-диаграмма приложения “Прайс”.

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

2.7 Проектирование приложения “Счета”

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

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

Рис.7 Приложение “Счет” – список счетов.

Основные операции для работы со списком счетов:

Добавить счет – создание нового счета. Входные данные: дата. Выходные данные – новый счет, измененный список счетов.

Удалить счет – удаляет счет из списка. Входные данные: счет(номер). Выходные данные – измененный список счетов.

Копировать счет – создает копию счета с теми же параметрами, но другим порядковым номером. Входные данные: счет(номер). Выходные данные – измененный список счетов.

Печать – вызывает диалог выбора отчета и его формата для печати. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные – *.xls или *.rtf файл или печатная форма.

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

Редактировать счет – вызывает форму для работы со счетом. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные – *.xls или *.rtf файл или печатная форма.

Рис.8 Приложение “Счет” – работа со счетом.

Основные операции для работы с содержимым счета:

Добавить товар – добавляет товар в счет. Входные данные: товар(номер). Выходные данные – измененный счет.

Удалить товар – удаляет товар из счета. Входные данные: товар(номер). Выходные данные – измененный счет

Сумма – вычисляет сумму товаров, включенных в счет. Входные данные: счет(номер). Выходные данные – сумма в долларах, рублях и евро.

Печать – вызывает диалог выбора отчета и его формата для печати счета. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные – *.xls или *.rtf файл или печатная форма.

Скидка – пересчитывает позиции счета с учетом скидки. Входные данные: размер скидки. Выходные данные – измененный счет.

Состояние – позволяет изменить состояние счета вручную. Входные данные: состояние. Выходные данные – счет.

UML-диаграмма приложения “Счет” представлена на рисунке 9.

Рис.9 UML-диаграмма приложения “Счет”.

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

2.8 Проектирование приложения “Склад”

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

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

Рис.10 Приложение “Склад” – Главная форма.

Основные операции для работы со складом перечислены ниже.

Со списком поставок:

Добавить поставку – создание новой поставки и включение ее в список. Входные данные: дата. Выходные данные – новая поставка, измененный список поставок.

Удалить поставку – удаляет поставку из списка. Входные данные: поставка(номер). Выходные данные – измененный список поставок.

Копировать поставку – создает копию поставки с теми же параметрами, но другим порядковым номером. Входные данные: поставка(номер). Выходные данные – измененный список поставок.

Печать – вызывает диалог выбора отчета и его формата для печати. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные – *.xls или *.rtf файл или печатная форма списка поставок.

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

Редактировать поставку – вызывает форму для работы с содержимым поставки. Входные данные: поставка(номер). Выходные данные содержимое поставки.

Пункты меню формы для работы с содержимым поставки:

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

Удалить товар – удаляет товар из поставки. Входные данные: товар(номер). Выходные данные – измененная поставка.

Сумма – вычисляет сумму товаров, включенных в поставку. Входные данные: поставка(номер). Выходные данные – сумма товаров в долларах, рублях и евро.

Печать – вызывает диалог выбора отчета и его формата для печати поставки. Входные данные: Шаблон для печати, если *.xls-отчет, то шаблон, если *.frf-отчет. Выходные данные – *.xls или *.rtf файл или печатная форма.

Пункт меню “Склад” – вызывает диалоговое окно для получения представления склада в разрезе товаров или времени.

UML-диаграмма приложения “Склад” представлена на рисунке 12.

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

Рис.12 UML-диаграмма приложения “Склад”.

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

2.9 Проектирование приложения “Заказы”

Приложение “Заказы” используется для получения конечного списка товаров и услуг, путем репликации заказов и счетов, а также внесением дополнительных позиций вне их (формирование заказа вручную). Целью его внедрения является получение плана закупок. Это возможно, благодаря механизму анализа состояния склада, который дает оперативную информацию о свободных и зарезервированных товарах. Отметим, что товары, пришедшие на склад, логически с заказами не связаны, так как для организации нет необходимости знать, товар из какой поставки был продан, важен лишь факт продажи единицы товара.

Основной принцип функционирования приложения можно разделить на следующие этапы:

Выбор счетов для генерации заказов

Получение списка товаров, содержащихся в счетах

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

Формирование плана закупок, то есть разбиение списка товаров по поставщикам.

Редактирование плана закупок, внесение недостающих товаров (с пометкой “Вне счетов”).

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

Внешний вид главной формы приложения показан на рисунке 13.

Основные функции приложения “Заказы”:

Добавить товар – добавление товара в заказ вне поставок. Входные данные: товар(номер). Выходные данные – список товаров для заказа

Удалить товар – удаление товара из списка товаров для заказа. Так как заказ не связан со счетом, то удалить можно и товар, заказываемый по счету. Входные данные: товар(номер). Выходные данные – список товаров для заказа.

Рис.13 Приложение “Заказы” – главная форма.

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

Расчет суммы – расчет суммарной стоимости для плана закупок. Входные данные: план закупок. Выходные данные – стоимость всех товаров плана.

Расчет суммы по заказу – расчет стоимости одного заказа. Входные данные: заказ. Выходные данные – стоимость всех товаров заказа.

Печать – вызывает диалог выбора отчета и его формата для печати. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные – *.xls или *.rtf файл или печатная форма списка поставок.

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

Сохранить план закупок – сохранение отчета по плану закупок в базе данных. Входные данные: отчет. Выходные данные – нет.

UML-диаграмма приложения “Заказы” представлена на рисунке 14

Рис.14 UML-диаграмма приложения “Заказы”.

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

Глава 3. Экспериментальная проверка программного комплекса.

3.1 Исходные данные и постановка задачи для проведения тестирования

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

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

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

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

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

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

добавление, изменение, удаление информации;

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

выполнение специальных задач, при возникновении нестандартных ситуаций.

3.2 Тестирование приложений

Тестирование приложения “Прайс”.

Прежде всего, была осуществлена попытка доступа к приложению, пользователем “Serebrinnikov_OA” с ролью “Склад”, которая дает права доступа к приложению “Склад” и, частично, “Заказы”, но не дает права доступа к приложению “Прайс”. Результат – отказ в доступе. После входа в систему под учетной записью администратора, были изменены права доступа для данного пользователя и эта учетная запись получила право на чтение, удаление, добавление товаров в прайс-листе. Добавим группу товаров “Нестандартное оборудование” с родителем “Все товары” в дерево товаров. Добавим в эту группу товар “Часы с флэш-накопителем 64Mb Casio-I32” и товар “ИК-порт ACTiSYS IR”. Добавление, удаление этих товаров из прайса, а также редактирование их свойств проходит нормально. При попытке удаление удаления товара “Монитор Sony Multiscan E100” получаем сообщение: “Товар “Монитор Sony Multiscan E100” не может быть удален, так как он включен в счет, заказ или поставку”. При удалении непустой группы товаров, при наличии в ней хотя бы одного товара, фигурирующего в счетах, заказах или поставках получаем такое же сообщение и все изменения в группе отменяются. Попытка другого пользователя изменить свойства товара, в то время, когда их редактирует пользователь “Serebrennikov_OA” приводит к появлению сообщения: “Редактирование текущей записи невозможно. Запись заблокирована пользователем Serebrinnikov_OA 13:20 19.02.2006”.

Тестирование приложения “Счета”.

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

3.3 Анализ результатов, полученных при тестировании

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

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

Рис. 15 Окно «Добро пожаловать».

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

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

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

Сеть функционирует нормально;

Если правильно указаны параметры подключения;

Сервер функционирует нормально;

Проверка работы поисков показала, что алгоритмы поисков работают

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

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

Соответственно, при несоблюдении каких-либо требований, в работе приложения возможно возникновение сбоев или ошибок.

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

Глава 4. Расчет экономической эффективности проекта

4.1 Анализ рыночных возможностей продукта

На рынке автоматизированных систем для крупных организаций и финансово-промышленных групп на сегодня можно выделить два основных субъекта: это рынок автоматизированных банковских систем (АБС) и рынок корпоративных информационных систем промышленных предприятий. Не смотря на сильную взаимосвязь этих двух рынков систем автоматизации, предлагаемые на них решения, пока еще не достаточно интегрированы между собой, чего следует ожидать в недалеком будущем. Создавая свои отделы и управления автоматизации, предприятия и банки пытались обустроиться своими силами. Однако периодическое "перетряхивание" инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, непрерывная работа программистов по удовлетворению все новых и новых пожеланий отдельных работников и как следствие - недовольство руководителей своими программистами несколько остудило пыл как тех, так и других. Итак, первый подход к решению этой проблемы сводился к проектированию "снизу-вверх". В этом случае, при наличии квалифицированного штата программистов, вполне сносно были автоматизированы отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривалась недостаточно хорошо, особенно в перспективе. Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов (для банков это в основном - расчетно-кассовое обслуживание, для промышленных предприятий - автоматизация процессов проектирования и производства, имеется в виду не конкретных станков и т.п., а информационных потоков). Учитывая тот факт, что ядром АИС безусловно является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начали с детальной проработки данной проблемы. Системы были спроектированы "сверху", т.е. в предположении, что одна программа должна удовлетворять потребности всех пользователей.

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

4.2 Расчет единовременных затрат на разработку ПО

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

Таблица 4.1.

Содержание стадий научно-исследовательской работы (НИР).

Стадии НИП	Содержание работ	Трудоемкость
		дни	%
Техническое задание	Изучение и анализ предметной области, изучение и анализ области внедрения, работа с консультантами, постановка задачи, составление и согласование технического задания с руководителем.	20	13,33
Эскизный проект	Построение концептуальной модели системы, описание входных и выходных данных, способов их преобразования. Разработка структур данных.	25	20,00
Технический проект	Разработка технического проекта. Построение структуры классов и определение способов их взаимодействия.	25	20,00
Рабочий проект	Написание программ, утилит и дополнительных модулей информационной системы, отладка программного обеспечения, тестирование.	60	33,34
Внедрение	Разработка справочной и технической документации, подготовка и защита отчета. Регистрация.	20	13,33
Итого:		150	100

Фактическая трудоемкость по стадиям проектирования представлена в виде таблицы (табл.4.1).

План-график выполнения приведен на рисунке 16:

Рис 16. План – график разработки и внедрения ПО (диаграмма Ганта).

Итак, общая фактическая трудоемкость разработки ПО составляет:

,

где – общая трудоемкость разработки, дни; Тi – трудоемкость по стадиям, дни; n – количество стадий разработки.

В смету затрат на разработку ПО включаются:

материальные затраты;

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

отчисления на социальные нужды;

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

стоимость инструментальных средств;

накладные расходы.

Материальные затраты.

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

В процессе работы использовались материалы и принадлежности, представленные в таблице 4.2.

Таблица 4.2.

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

Наименование	Количество, шт.	Цена, руб.	Стоимость, руб.
Дискеты	5	14	70
Бумага	400	0,4	160
Ватман	5	10	50
Ручка	2	5	10
CD-RW диск	2	30	60
Дипломная папка	2	15	30
Картридж	1	150	150
Итого:			530

Основная и дополнительная заработные платы.

Основная заработная плата при выполнении НИР включает зарплату всех сотрудников, принимающих непосредственное участие в разработке ПО. В данном случае необходимо учитывать основные зарплаты разработчика (студента), руководителя дипломного проекта, консультанта по экономической части. Таким образом, основная заработная плата З_осн при выполнении НИР рассчитывается по формуле:

,

где З_ср.дн.j – среднедневная зарплата j-го сотрудника, руб./день; Т_об.j – общая трудоемкость проекта j-го сотрудника, дни; n – количество сотрудников, принимающих непосредственное участие в разработке ПО.

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

.

Заработная плата дипломного руководителя составляет 60 руб./час, причем на консультацию запланировано 23 часа. Следовательно, основная зарплата руководителя дипломного проекта за весь период разработки равна:

.

Заработная плата консультанта по экономической части составляет 50 руб./час, причем на консультацию запланировано 3 часа. Следовательно, основная зарплата консультанта по экономике за весь период разработки равна:

.

В итоге основная заработная плата при выполнении НИР равна:

.

Дополнительная заработная плата равна 10% от основной:

.

Итого основная и дополнительная заработная плата составляют:

.

Отчисления на социальные нужды.

Отчисления на социальные нужды составляют на сегодняшний день 26% от общего фонда заработной платы, следовательно:

.

Стоимость машинного времени на подготовку и отладку программ.

Стоимость машинного времени З_омв зависит от себестоимости машино-часа работы ЭВМ С_МЧ, а также времени работы на ЭВМ Т_ЭВМ, и включает амортизацию ЭВМ и оборудования, затраты на электроэнергию, зарплату обслуживающего персонала.

Себестоимость машино-часа ЭВМ и принтера равны соответственно:

,

.

Время работы на ЭВМ и принтере равны соответственно:

.

Затраты на оборудование.

,

где А_М – амортизационные отчисления, руб.; О_ф – стоимость ЭВМ и оборудования, руб.; Н_ам – норма амортизации, %; Т_м – время использования оборудования, дни

Затраты на электроэнергию.

,

Затраты на обслуживающий персонал.

Данный вид затрат отсутствует.

Таким образом, стоимость машинного времени на подготовку и отладку программ равно:

Стоимость инструментальных средств.

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

Таблица 4.3. Стоимость СПО.

Программное обеспечение	Стоимость, руб.
MS WINDOWS 2000 Prof	2420.00
Delphi 7	12400.00
Microsoft Office XP Professional	6311.00
Итого:	21131

Затраты на амортизацию инструментальных средств:

руб.

Расчет стоимости машинного времени

;

руб./ч.

Накладные расходы.

Накладные расходы составляют 30% от основной заработной платы разработчиков ПО, а значит:

.

Итак, смета затрат на НИР приведена в таблице 4.4.

Таблица 4.4.

Смета затрат на разработку ПО.

Элемент затрат	Стоимость, руб.
Материальные затраты	530.00
Основная и дополнительная зарплата	59598
Отчисления на социальные нужды	15495,48
Оплата машинного времени	1652,18
Стоимость инструментальных средств	1454,56
Накладные расходы	16245
Итого:	94975,22

4.3 Единовременные расходы организации заказчика ПО при внедрении автоматизированных рабочих мест (АРМ)

К единовременным затратам пользователя программного обеспечения K_общ относятся затраты на оплату:

программного обеспечения Ц_по;

инструментальных средств Ц_ис;

ЭВМ, прочих аппаратных средств и сетевого оборудования К_эвм;

обучение персонала К_осв.

Стоимость программного обеспечения.

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

,

где С_по – себестоимость ПО, затраты на разработку по смете из таблицы 5.4; П – прибыль разработчика 20–30% к затратам; НДС – налог на добавленную стоимость 18%.

Итак, стоимость программного обеспечения равна:

Стоимость инструментальных средств.

Стоимость инструментальных средств и годовых сумм амортизации приведены в таблице 4.5.

Таблица 4.5.

Расчет стоимости и амортизационных отчислений инструментальных средств.

Виды ПО	Стоимость, руб.	Норма амортизации, %	Амортизационные отчисления, руб.
MS WINDOWS Millenium	2234.00	30	670.20

Стоимость ЭВМ, прочих аппаратных средств и сетевого оборудования.

Стоимость всего необходимого оборудования и годовых сумм амортизации приведены в таблице 4.6.

Таблица 4.6.

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

Наименование оборудования	Количество	Цена, руб.	Стоимость, руб.	Норма амортизации, %	Амортизационные отчисления, руб.
ПК	1 шт.	20000.00	20000.00	30	6000.00
Сетевая розетка	1 шт.	8.00	8.00	30	2.40
Кабель UTP5	5 м	4.00	20.00	30	6.00
Хозяйственный инвентарь (мебель)	1 шт.	8000.00	8000.00	10	800.00
Итого:			28028.00		6808.4

Затраты на обучение персонала.

Затраты организации на освоение ПО и обучение персонала работе с программой и ЭВМ производятся по формуле:

К_осв = З_час * Ч_пр* Т_осв = 25 * 4 * 40+25*1*48 = 5200.00(руб.),

где З_час – часовая зарплата программиста (З_час = 25.00 руб./час);

Ч_пр - численность персонала на обучение (Ч_пр = 4 чел.);

Т_осв – продолжительность обучения и освоения (Т_осв = 40 часов).

Таким образом, на обучение четырех человек необходимо затратить 40 часов. Для руководителя необходим 48-часовой курс обучения.

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

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

Таблица 4.7

График реализации проекта.

Этапы реализации	1	2	3	4	5	6	7	8
Техническое задание	20
Эскизный проект		20	5
Технический проект			15	10
Рабочий проект				10	20	20	10
Внедрение							10	10
Покупка оборудования

	5
Обучение персонала								11

Результаты расчетов оформлены в виде инвестиционного плана (таблица 4.8).

Таблица 4.8

Инвестиционный план.

Этапы реализации	1	2	3	4	5	6	7	8
Техническое задание	16809,68
Эскизный проект		16809,68	8404,84
Технический проект			8404,84	8404,84
Рабочий проект				8404,84	16809,68	16809,68	8404,84
Внедрение							8404,84	16809,68
Покупка оборудования					28028
Обучение персонала								5200
Итого:	16809,68	16809,68	16809,68	16809,68	44837,68	16809,68	16809,68	22009,68

4.4 Источники финансирования проекта

Общие инвестиции проекта составляют 167705 рублей 46 копеек. Источниками финансирования являются собственные средства – 80% (134164 рубля 37 копеек) и кредит коммерческого банка, под 12% годовых – 20% (33541 рубля 00 копеек) на 2 года.

Возврат кредита осуществляется в конце второго года, а со второго месяца выплачиваются проценты (1.5%). Приведем расчеты в таблице 4.9.

Таблица 4.9

Расчеты за кредит.

Показатель	Годы
	1	2
Возврат кредита, руб.	-	33541.00
Сумма непогашенного долга, руб.	33541.00	33541.00
Проценты за кредит, руб.	4024.92	4024.92
Итого к оплате, руб.	4024.92	37565.92

Сумма всех выплат по истечении срока составит 37565 рублей 92 копейки.

4.5 Текущие расходы пользователя ПО при эксплуатации АРМ

Текущие расходы пользователя при внедрении АРМ учитывают затраты в год на:

амортизацию оборудования, ПО и инструментальных средств;

материалы (картриджи и бумага);

электроэнергию;

обтирочные и смазочные материалы;

ремонт оборудования.

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

Данные по амортизации оборудования и ПО расположены в таблицах 4.5, 4.6.

Материалы.

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

Таблица 4.10

Материалы, использующиеся в процессе эксплуатации.

Наименование	Количество, шт.	Цена, руб.	Стоимость, руб.
Бумага	4000	0,4	1600
Картридж	1	150	150
Итого:			1750

Электроэнергия.

Затраты на электроэнергию посчитаем по формуле:

где С_ЭВМ, С_принт. – стоимость машино-часа ЭВМ и принтера соответственно;

Т_{сут.ЭВМ}, Т_{сут.принт.} – суточное время работы ЭВМ и принтера соответственно;

Т_год – время рабочих дней в году.

Обтирочные и смазочные материалы.

Стоимость обтирочных материалов равна 40 рублей 00 копеек.

Ремонт оборудования.

Ремонт оборудования составляет 5% от стоимости. Значит:

К_5% = К_ЭВМ * 0.05 = 28028.00 * 0.05 = 1401.4 (рублей).

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

Таблица 4.11

Смета текущих расходов.

Затраты на:	Расходы, руб.
амортизацию оборудования, ПО и инструментальных средств	7478.60
материалы	1750.00
электроэнергию	965.00
обтирочные и смазочные материалы	40.00
ремонт оборудования	1401.40
Итого:	11635

4.6 Экономия текущих затрат пользователя ПО

Основными источниками экономии организации при создании АРМ специалистов являются:

экономия затрат за счет ускорения документооборота;

экономия за счет быстрой реакции на изменение предпочтений покупателей

экономия затрат на заработную плату;

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

а также обеспечивается экономия за счет:

Экономия затрат за счет ускорения документооборота.

В результате внедрения АРМ происходит ускорение документооборота, что является “узким” местом любой торговой организации, а значит и увеличение клиентской базы и объемов продаж. Это действительно серьезная проблема, особенно в свете постепенного выхода компании на рынок розничных продаж. По оценкам специалистов экономия составит не менее 18000 рублей в месяц или не менее 216000 в год. Более оперативная работа с поставщиками позволит снизить процент выплат по товарному кредиту и снизить вероятность штрафных платежей за несвоевременную поставку – при самом неблагоприятном стечении обстоятельств порядка 25000 рублей в месяц. Значит, экономия будет составлять минимум 300000 рублей в год. Экономия за счет быстрой реакции на изменение предпочтений покупателей.

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

Экономия затрат на заработную плату за счет сокращения численности персонала.

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

,

где DЧ – сокращение численности;

З_мес – оплата труда в месяц, (3500 руб.);

Т_эф – эффективный фонд рабочего времени в год, (12 месяцев);

Х - размер доплат, премий,(100%);

Y – отчисления на социальные нужды, (26%).

С учетом освобождения компьютерной техники и хозяйственного инвентаря экономия составит Э=105840+28500=134340 руб.

Экономия материальных ресурсов за счет сокращения количества и унификации отчетных форм.

В результате внедрения АРМ появится возможность экономии материальных затрат за счет сокращения количества расходных материалов в размере 4700 рублей.

Таким образом, общая экономия после внедрения АРМ составит:

Э_общ. = 516000+60000 + 105840 + 4700 = 686540 (рублей).

Финансовый план проекта.

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

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

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

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

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

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

Таблица 4.12

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

	Месяцы												Годы
	1	2	3	4	5	6	7	8	9	10	11	12	1 год	2 год
I.Инвестиционная деятельность

 

Техническое задание

16809,68

 

 

 

 

 

 

 

 

 

 

 

 

 

Эскизный проект

 

16809,68

8404,84

 

 

 

 

 

 

 

 

 

Технический проект

 

 

8404,84

8404,84

 

 

 

 

 

 

 

 

 

 

Рабочий проект

 

 

8404,84

16809,68

16809,68

8404,84

 

 

 

 

 

 

 

Внедрение

 

 

 

 

 

 

8404,84

16809,68

 

 

 

 

 

 

Покупка оборудования

 

 

28028

 

 

 

 

 

 

 

 

Обучение персонала

 

 

 

 

 

 

 

5200

 

 

 

 

 

 

Итого:

-16809,68

-16809,68

-16809,68

-16809,68

-44837,68

-16809,68

-16809,68

-22009,68

 

 

 

 

 

 

II.Операционная деятельность

 

 

 

 

 

 

 

 

Увеличение дохода при внедрении

 

 

 

 

 

 

 

 

57211,67

57211,67

57211,67

57211,67

686540,00

686540,00

Текущие затраты

 

 

 

 

 

 

 

 

Амортизация

 

 

 

 

 

 

 

 

969,58

969,58

969,58

969,58

11635,00

11635,00

Проценты за кредит

 

335,41

335,41

335,41

335,41

335,41

335,41

335,41

335,41

335,41

335,41

335,41

4024,92

0,00

Прирост валовой прибыли

 

-335,41

-335,41

-335,41

-335,41

-335,41

-335,41

-335,41

55906,67

55906,67

55906,67

55906,67

670880,08

674905,00

Налог (24%)

 

 

 

 

 

 

 

 

13417,60

13417,60

13417,60

13417,60

161011,22

161977,20

Прирост чистой прибыли

 

-335,41

-335,41

-335,41

-335,41

-335,41

-335,41

-335,41

42489,07

42489,07

42489,07

42489,07

509868,86

512927,80

Итого:

 

-335,41

-335,41

-335,41

-335,41

-335,41

-335,41

-335,41

43458,66

43458,66

43458,66

43458,66

521503,86

524562,80

III.Финансовая деятельность

 

 

 

 

 

 

 

 

 

 

 

 

 

 

собственные средства

23576,50

23576,50

23576,50

23576,50

45180,00

23576,50

23576,50

22400,00

 

 

 

 

 

 

кредит

5590,20

5590,20

5590,20

5590,20

 

5590,20

5590,20

 

 

 

 

 

 

 

возврат кредита

 

 

 

 

 

 

 

 

 

 

 

 

33541,00

 

Итого:

29166,70

29166,70

29166,70

29166,70

45180,00

29166,70

29166,70

22400,00

0,00

0,00

0,00

0,00

33541,00

0,00

Сальдо денежной наличности

12357,02

12021,61

12021,61

12021,61

6,91

12021,61

12021,61

54,91

43458,66

43458,66

43458,66

43458,66

555044,86

524562,80

Нарастающим итогом

12357,02

24378,63

36400,24

48421,85

48428,76

60450,37

72471,98

72526,89

115985,55

159444,20

202902,86

246361,51

801406,37

1325969,17

III.Финансовая деятельность

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Таблица 4.13

Денежные потоки.

Показатели	Месяцы												Годы
	1	2	3	4	5	6	7	8	9	10	11	12	1 год	2 год
Инвестиционная деятельность	-16809,68	-16809,68	-16809,68	-16809,68	-44837,68	-16809,68	-16809,68	-22009,68	0,00	0,00	0,00	0,00	0,00	0,00
Операционная деятельность	0,00	-335,41	-335,41	-335,41	-335,41	-335,41	-335,41	-335,41	43458,66	43458,66	43458,66	43458,66	521503,86	524562,80
Чистый денежный поток	-16809,68	-16474,27	-16474,27	-16474,27	-44502,27	-16474,27	-16474,27	-21674,27	43458,66	43458,66	43458,66	43458,66	521503,86	524562,80
Коэффициент дисконтинирования	0,992	0,984	0,976	0,969	0,961	0,953	0,946	0,938	0,931	0,923	0,916	0,909	0,926	0,857
Дисконтинированный денежный поток	-16675,20	-16210,68	-16085,13	-15957,47	-42764,12	-15705,18	-15580,54	-20335,75	40451,21	40130,17	39811,67	39495,71	482912,58	449550,32
NPV	-16675,20	-32885,88	-48971,01	-64928,49	-107692,60	-123397,78	-138978,32	-159314,07 -118862,87 -78732,70 -38921,03 574,68 483487,26 933037,58 Дисконтированный доход 0 -347,775 -344,588 -341,401 -338,567 -335,38 -332,193 -329,36 40497,3 40145,87 39750,56 39399,17 424298,8 382883,1 Капитальные вложения -10943,8 -10844,4 -10745 -10645,7 -39264,1 -10457,9 -10358,5 -9971,09 0 0 0 0 0 0 SRR -8,51895 4.7 Показатели экономической эффективности проекта Международная практика в процессе оценки проектов использует несколько обобщающих показателей. К таким показателям относятся: интегральный экономический эффект; индекс доходности; внутренний коэффициент эффективности; период возврата капитальных вложений и срок окупаемости. Интегральный экономический эффект (NPV – Net Present Value of Discounted Cash Flow). NPV представляет собой чистую текущую стоимость проекта. Она определяется путем вычисления разности совокупного дохода за весь период функционирования проекта и всех видов расходов, суммированных за тот же период с учетом дисконтирования. Результаты расчета NPV представлены в виде таблицы 5.13. Годовую ставку дисконтирования возьмем равной: . Коэффициент дисконтирования за год равен: . В месяц коэффициент дисконтирования равен: . Итоговое значение NPV равно 928524 рубля 79 копеек. Индекс доходности. Определяется как отношение суммарного дисконтированного дохода к суммарным дисконтированным капитальным вложениям: . Внутренний коэффициент эффективности. Определяется как пороговое значение рентабельности, при котором NPV равно нулю где r1 – исходная ставка дисконтирования; r2 – ставка дисконтирования, при которой NPV < 0; rпор – внутренний коэффициент эффективности проекта; NPVr1, NPVr2 – NPV соответственно при r1 и r2. Подберем ставку дисконтирования, при которой NPV < 0: r2 = 91,6%, NPVr2 = -38921,03. Тогда: , значит проект считается эффективным. Срок окупаемости и срок возврата вложений. Определим срок окупаемости и срок возврата вложений сначала аналитическим способом: , где tx – количество периодов, при которых NPV < 0; NPVt – последнее отрицательное значение NPV; ДДПt+1 – величина ДДП в “t+1”-м периоде. Графический способ. Финансовый профиль проекта представляет собой график изображения величины кумулятивной чистой текущей стоимости во времени. На рисунке 1 представлен финансовый профиль данного проекта. Рис 1 Финансовый профиль. Выводы по главе. Проанализировав рассчитанные показатели эффективности проекта, можно сказать, что внедрение данного проекта является экономически эффективным. Об этом говорит: срок окупаемости проекта – 1,9 года; положительное сальдо реальных накопленных денег; пороговое значение рентабельности больше ставки дисконтирования (0,51>0,08). положительность интегрального экономического эффекта (NPV=928524,79 руб >0); индекс доходности больше 1 (SRR = 6,75 >1); В результате применение данной разработки позволит компенсировать затраты на разработку и эксплуатацию, получить экономический эффект от использования данного комплекса. В ходе вычислений были получены следующие результаты: Была рассчитана смета затрат на разработку программного продукта, итоговая сумма которой равняется: 94975,22 руб. Был рассчитан экономический эффект от внедрения программного продукта, который составил: 483487,26 рублей в год. Заключение В данной дипломной работе предлагается внедрить автоматизированную систему торговой деятельности для предприятия ЗАО «Polycomm». Создание данной системы необходимо, т.к. она может обеспечить техническую возможность выхода на рынок розничных продаж, а так же позволит сохранить конкурентоспособность на рынке за счет повышения эффективности производства и имиджа компании. Разработанная автоматизированная система управления кредитным портфелем позволяет: автоматизировать процесс работы со счетами клиентов; предоставить возможность оперативного учета, т.е. регистрация операций продажи в реальном масштабе времени; автоматизировать процесс складского учета. Результатами внедрения автоматизированной системы управления кредитным портфелем будет: повышение качества работы за счет уменьшения объема трудоемких операций с бумажными документами, ускорения выполнения операций и уменьшения количества ошибок; обеспечение аналитических функций для учета торговой деятельности в разрезе товаров; повышение эффективности выполнения работ сотрудников. В результате применение данной разработки позволит, бесспорно, компенсировать затраты на разработку и эксплуатацию, получить экономический эффект от использования данного комплекса. В ходе вычислений были получены следующие результаты: Были рассчитаны затраты на разработку программного продукта, итоговая сумма которой равняется: 94975,22 руб.; срок окупаемости проекта – 1,9 года; положительное сальдо реальных накопленных денег; пороговое значение рентабельности больше ставки дисконтирования (0,51>0,08) положительность интегрального экономического эффекта (NPV=928524,79 руб >0); индекс доходности больше 1 (SRR = 6,75 >1); Таким образом, внедряемая автоматизированная система ведения торговой деятельности в данной работе является необходимой и экономически выгодной. Список литературы Тихомиров А.В. Введение в информационный бизнес. – М.: Финансы и статистика, 1996. Компания «Оптима». www.optima.ru Агентство Вeafnd. www.beafnd.ru Компания SAP. www.sap.com Компания Оracle. www.oracle.ru Компания Вaan. www.baan.ru Компания ROSS Systems. www.rossinc.ru Компания SYMEX. www.frontstep.ru Компания Damgaard Data Int. www.damgaard.ru Компания QAD.www.qad.ru Корпорация «Парус». www.parus.ru Корпорация «Галактика». www.galactica.ru Компания «АйТи». www.it.ru Компания 1С. www.1c.ru Система Erwin. www.iterface.ru СУБД Oracle. www.suncis.ifmo.ru 1. Реферат Развитие и становление экологического права в России 2. Реферат Принципы бухгалтерского учета требования 3. Сочинение Любовная лирика Афанасия Фета 4. Реферат на тему Then War In America Essay Research Paper 5. Лекция Лекции по Экономике 2 6. Реферат Определение оптимальной специализации производства и сочетания отраслей в сельскохозяйственном п 7. Реферат на тему Colgate In Argentina Essay Research Paper Colgate 8. Биография Врачев, Иван Яковлевич 9. Биография на тему Куравлев Леонид Вячеславович 10. Реферат Рейхсмаршал Bukvasha Правила Контакты