Обзор средств автоматизации торговли. Обзор состояния Интернет-торговли и роли в них аукционов. Описание процесса проектирования автоматизированной системы. Расчет экономической эффективности от внедрения программного продукта. Охрана труда работников.
При низкой оригинальности работы "Разработка автоматизированной системы управления торговым предприятием", Вы можете повысить уникальность этой работы до 80-100%
Причем слово «качество» понимается как в прямом смысле (надежность, производительность, масштабируемость), так и в смысле продвинутой функциональности, расширяемости (силами пользователя или независимых сервисных фирм). Маленькие же фирмы, коими являются все без исключения фирмы на белорусском рынке, не в состоянии обеспечить инфраструктуру для разработки столь мощного ПО. Для обеспечения надежности и сокращения сроков разработок можно применять 4GL-языки, CASE и RAD-средства, а также отдельные продукты независимых поставщиков. Такой выбор на долгие годы связывает нас с выбранной когда-то технологией и порой, чтобы перейти на новую технологическую платформу, необходимо полностью переписать продукт. Изза этого разработчик начинает создавать или универсальную систему, охватывающую всю деятельность предприятия, но делающую это в расчете на «среднее» предприятие, или профессиональную и очень гибкую, но рассчитанную на автоматизацию узкой задачи программу.А на современном этапе руководителю важно иметь информацию не только о достигнутых успехах (давать оценку уже свершившимся фактам), но создавать на предприятии комплексные информационные системы, позволяющие ему осуществлять мониторинг всей финансово-хозяйственной деятельности предприятия - отслеживание протекающих на предприятии процессов в режиме реального времени; составление оперативных отчетов о результатах работы за короткие промежутки времени; сравнение целевых результатов с фактически достигнутыми. Это поможет ориентироваться в большом многообразии предлагаемых решений, определить, какая же именно система нужна вашему предприятию, и сделать обоснованный выбор. Представители групп БЭСТ, Инотек, ИНФИН, Инфософт, Супер-Менеджер, Турбо-Бухгалтер, Инфо-Бухгалтер, и еще более 100 систем Concorde XAL, Exact NS-2000, Platinum, PRO/MIS, Scala, SUNSYSTEMS, БОСС-Корпорация, Галактика/Парус Ресурс Эталон ACCPAC/2000 (СА) JD Edwards (Robertson & Blums), MFG-Pro (QAD/BMS), SYTELINE (СОКАП/SYMIX), Renaissance CS (ROSS Systems), PRMS (Acacia Technologies) SAP/R3 (SAP AG), Baan (Baan), BPCS (ITS/SSA), Oracle Applications (Oracle) Системами этой группы может воспользоваться практически любое предприятие, которому необходимо управление финансовыми потоками и автоматизация учетных функций (например, БЭСТ, Парус). Системы этого класса по многим критериям универсальны, хотя зачастую разработчиками предлагаются решения отраслевых проблем, например, особые способы начисления налогов или управление персоналом с учетом специфики регионов.Прежде всего, необходимо предложить подход к классификации управленческих информационных систем, позволяющий предприятию более четко формировать список стратегических и операционных задач управления и определять критерии для выбора системы. Достаточно длительное время использовалась классификация, предложенная российским экспертом Игорем Карпачевым, подразделяющая системы на четыре класса (локальные - системы для малого бизнеса, финансово-управленческие, средние интегрированные и крупные интегрированные) в зависимости от типа предприятия. Нечеткость определений в классификации Карпачева позволяет многим компаниям свободно манипулировать устоявшимися на западном рынке терминами и перемещать предлагаемую ими систему из одного класса в другой с целью вывести ее на один уровень с западными ERP-системами. Исходя из значения термина «эффективность», эффективность внедрения информационной системы можно определить как достижение оптимального соотношения затраты/результат, под которым понимается сопоставление экономического результата внедрения системы и затрат на приобретение, установку, доработку, эксплуатацию системы. Критики существующих моделей оценки эффективности внедрения ERP указывают на то, что большинство подходов не позволяют оценить ход реализации проекта по внедрению ERP и корректировать возникающие отклонения от намеченных планов на разных стадиях, вплоть до начальной.Тем не менее, некоторые проблемы, возникающие при внедрении системы, достаточно хорошо изучены, формализованы и имеют эффективные методологии решения. Заблаговременное изучение этих проблем и подготовка к ним значительно облегчают процесс внедрения и повышают эффективность дальнейшего использования системы. Далее приведены основные проблемы и задачи, возникающие в большинстве случаев при внедрении систем управления и рекомендации по их решению. Основные проблемы и задачи, требующие особого внимания при их решении: 1) отсутствие постановки задачи менеджмента на предприятии; При внедрении корпоративных информационных систем в большинстве случаев возникает активное сопротивление сотрудников на местах, которое является серьезным препятствием для консультантов и вполне способно сорвать или существенно затянуть проект внедрения.Вместо традиционных витрин из стекла и камня, здесь все существует в виде битов и байтов, перемещающихся по Интернет, а управляет всем этим как раз программное обеспечение для электронной коммерции. Чтобы заняться данным видом бизнеса, компании необходим
План
Содержание
ВВЕДЕНИЕ
1. Автоматизированные системы управления предприятием
1.1. Компьютерные системы управления предприятием
1.2. Три уровня эффектов от ИТ-проектов
1.3. Принципы классификации систем управления
1.4. Стоимость проекта АСУТП
1.5. Внедрение системы автоматизации, основные проблемы и задачи
2. Торговое предприятие во всемирной компьютерной сети
2.1. Электронная коммерция
2.2. Интернет-аукционы
3. Проектирование и реализация АСУТП
3.1. Язык программирование Java
3.2. Концепция Business Engine
3.3. Общее представление АСУТП
3.4. Основные технические решения.
3.5. Структура системы
3.6. Взаимосвязь со смежными системами.
3.7. Подсистемы
3.8. Проектирование. Построение диаграмм39
4. Экономический раздел
4.1. Описание задачи
4.2. Расчет времени на создание программного продукта
4.3. Расчет заработной платы исполнителя работ
4.4. Расчет начислений на заработную плату
4.5. Расчет себестоимости 1-го машино-часа работы ПЭВМ
4.6. Расчет расходов на содержание и эксплуатацию ПЭВМ
4.7. Расчет себестоимости программного продукта
4.8. Расчет цены программного продукта
5. Охрана труда
5.1. Мероприятия по охране труда
5.2. Производственная санитария
5.3. Мероприятия и факторы
5.4. Ситуации и безопастность
Заключение
Список использованных источников
Введение
Современный бизнес диктует все более и более жесткие требования к качеству создаваемого программного обеспечения (ПО). Причем слово «качество» понимается как в прямом смысле (надежность, производительность, масштабируемость), так и в смысле продвинутой функциональности, расширяемости (силами пользователя или независимых сервисных фирм).
Создать отвечающий этим требованиям программный продукт на современном уровне - непростая задача. Под силу она, пожалуй, только большим корпорациям. Причем речь идет о корпорациях масштаба Microsoft или Oracle. Маленькие же фирмы, коими являются все без исключения фирмы на белорусском рынке, не в состоянии обеспечить инфраструктуру для разработки столь мощного ПО.
Для обеспечения надежности и сокращения сроков разработок можно применять 4GL-языки, CASE и RAD-средства, а также отдельные продукты независимых поставщиков. Но такой подход решает только технические вопросы. Причем, выбирая средства разработки, мы связываем себя с конкретной технологией (например, с файл-серверной или с двухуровневой клиент-сервер). Такой выбор на долгие годы связывает нас с выбранной когда-то технологией и порой, чтобы перейти на новую технологическую платформу, необходимо полностью переписать продукт. Если даже вы недавно выбрали самую новую технологию (например, многоуровневую технологию клиент-сервер), то можно с уверенностью сказать, что через несколько лет появится новая (лучшая технология) и вам (если, конечно, вы захотите на нее перейти) снова придется переписывать ваш продукт.
Но все эти проблемы меркнут перед тем, что относительно маленькой фирме просто физически не удастся полно и качественно (со всеми нюансами и тонкостями) реализовать все многообразие функций, встречающихся в мире бизнеса. Изза этого разработчик начинает создавать или универсальную систему, охватывающую всю деятельность предприятия, но делающую это в расчете на «среднее» предприятие, или профессиональную и очень гибкую, но рассчитанную на автоматизацию узкой задачи программу. Похоже, проблемы обоих подходов понятны всем без объяснения.
Если в свое время бухгалтеры и финансисты четко представляли себе, какие задачи им нужно решить с помощью программных средств, то с интегрированными системами ситуация иная. Многие руководители просто не знают, что они хотят улучшить за счет автоматизации. По словам вице-президента компании «АЙТИ» по исследованиям и разработкам Александра Миронова, наблюдается «неосознанное понимание» потребности в автоматизации управления с «неосознанными» же пока задачами. Так, по данным корпорации «Парус», около половины потенциальных потребителей ПО руководствуется при выборе систем известностью торговой марки и только 16% - технологическими параметрами, то есть качеством системы.
Единственный способ деления рынка интегрированных систем управления предприятием (АСУТП), который прочно закрепился в сознании как потенциальных клиентов, так и разработчиков, - это исторически сложившееся деление по месту производства. Все знают, что есть «очень дорогие» западные и более доступные отечественные системы. В результате допускается сразу две ошибки. Во-первых, что касается цен, дешевизна отечественных систем всего лишь миф, который развеивается по мере роста масштабов АСУТП или предприятия-заказчика. Во-вторых, при таком подходе почти невозможно сравнивать реальное качество систем.
Между тем единственное, что различает АСУТП, это именно качество, а оно зависит от двух параметров: задач, которые решает система, и соответствующих этим задачам и заложенных в систему управленческих функций. Белорусские разработчики привыкли козырять тем обстоятельством, что их программные продукты в отличие от западных соответствуют некоему «третьему пути», по которому развивается отечественный менеджмент. Выражается это якобы в меньшей жесткости, большей настраиваемости белорусских АСУТП на индивидуальный стиль конкретного руководителя или компании. И этим, по сути, подменяется идея классификации АСУТП по решаемым ими управленческим задачам.
Очевидно, что стандарт ERP, предусматривающий управление всеми ресурсами предприятия, включая иногда его партнеров и клиентов, с полным набором управленческих воздействий на процесс, применительно к отечественным разработкам вообще пока не обсуждается.
В ответ на упреки многие белорусские разработчики и консультанты утверждают, что к системам типа MRP II и ERP отечественный рынок просто не готов. По словам Александра Карпачева (корпорация «Парус»), «все внедряют финансовые системы и логистику, чтобы эффективно управлять тем, что в дефиците, - деньгами. А производственные мощности и рабочая сила пока не в дефиците, производство недогружено. Нет острой потребности в повышении его эффективности и, следовательно, в автоматизации». Сходную точку зрения высказал и вице-президент группы Aquarius Владимир Дрожжинов: «Программные продукты этого класса (ERP) рассчитаны на определенный уровень насыщения рынка. На Западе компании бьются за доли процентов. А если у нас все и так растет, и станки загружены на 50%, о каких сложных системах можно говорить?».
Белорусским разработчикам ПО разумнее было бы отказаться от конкуренции с мировыми лидерами в создании универсальных продуктов. То есть надо более четко обозначить свой круг интересов - по отраслям и масштабам бизнеса клиента.
Однако сейчас так поступает меньшинство из разработчиков. Скажем, компания «1С» заявляет, что работает только с малым бизнесом, а «Парус» - со средним. Что касается отраслевой специализации, то среди клиентов одного и того же производителя ПО можно встретить обычно нефтегазовые, энергетические, строительные, машиностроительные, пищевые, фармацевтические, торговые предприятия, а также государственные и образовательные учреждения. Отсутствие опыта и специалистов-предметников приводит к тому, что создаются некие недифференцированные, максимально обобщенные шаблоны, под которые предлагается «подогнать» реальное производство. Тогда как оно делится на дискретное и непрерывное, единичное, серийное и массовое, а эти типы - на еще более мелкие и т. д. Сузив границы специализации, разработчики могли бы направить освободившиеся ресурсы на достижение необходимого на сегодняшний день качества продукта и сосредоточиться на полноте решаемых системой управленческих задач и интегрированности управленческих функций. В этом случае они могли бы составить конкуренцию зарубежным коллегам из среднего сегмента.
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы