Файл: Корпоративные информационные системы (совокупность информации).pdf

ВУЗ: Не указан

Категория: Эссе

Дисциплина: Не указана

Добавлен: 14.07.2023

Просмотров: 126

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

- цикл получения дохода – от накладной до получения наличных;

- управление взаимозависимостью сложных спецификаций материалов

- проверка на соответствие бланков заказов (что было заказано), квитанций о поступлении товаров (что было получено) и затрат (счет-фактура от производителя)

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

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

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

Недостатки

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

Ограничения ERP-систем заключаются в следующем:

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

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

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

- Перепроектирование бизнес-процессов под «промышленный стандарт», поддерживаемый ERP-системой, может привести к потере конкурентоспособности фирмы.


- Установка ERP-систем может быть очень дорогостоящей.

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

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

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

- ERP-системы могут быть сложны в использовании.

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

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

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

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

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

- Часто возникают проблемы с совместимостью с устаревшими системами партнеров.

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

Этапы разработки КИС

Классический жизненный цикл

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

Чаще классический жизненный цикл называют КАСКАДНОЙ или ВОДОПАДНОЙ моделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий иерархически нижний этап происходит только после полного завершения работ на текущем этапе и возврата к пройденным этапам не предусматривается. (см. рис. ниже)



Рис. Классический жизненный цикл разработки ПО

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

- анализ,

- проектирование,

- кодирование (реализация),

- тестирование,

- сопровождение

При этом моделируются действия стандартного инженерного цикла.

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

Анализ начинается с определения требований и назначения подмножества этих требований программному элементу.

На этом этапе начинается решение задачи планирования проекта ПО.

В ходе планирования проекта определяются:

- объем проектных работ,

- риск проектных работ,

- необходимые трудозатраты,

- формируются рабочие задачи,

- формируется план-график работ.

Анализ требований, относящийся к программному элементу, т.е. к ПО, уточняет и детализирует:

- функции ПО,

- характеристики ПО,

- интерфейс ПО.

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

Проектирование создает представления:

- архитектуры ПО,

- модульной структуры ПО,

- алгоритмической структуры ПО,

- структуры данных,

- входного и выходного интерфейса (входных и выходных форм данных).

Кодирование (реализация) состоит в переводе результатов проектирования в текст на языке программирования.

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

Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений:

- исправление ошибок,

- адаптация к изменениям внешней для ПО среды,

- усовершенствование ПО по требованию заказчика.

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

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

Достоинствами классического жизненного цикла являются:

- получение плана и временного графика по всем этапам проекта,

- упорядочение хода разработки.

К недостаткам классического жизненного цикла относятся:

- частое отклонение реальных проектов от стандартной последовательности шагов,


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

- доступность результатов проекта заказчику лишь в конце работы.

ЭВОЛЮЦИЯ КИС

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

Рис.1 Основные исторически сложившиеся классы систем управления предприятиями

Системы MRP

Системы MRP(Material Requirements Planning) – это системы планирования требований на материалы, позволяющие оптимально загружать производственные мощности, и при этом закупать именно столько материалов и сырья, сколько необходимо для выполнения текущего плана заказов и именно столько, сколько возможно обработать за соответствующий цикл производства.

Системы MRP II

Системы MRP II (Manufacturing Resource Planning) – это системы планирования производственных ресурсов. Основная цель - учитывать и анализировать все коммерческие и производственные события в производстве: всё то, что происходит в данный момент и всё то, что запланировано на будущее. Как только в производстве допущен брак, как только изменена программа производства, как только в производстве утверждены новые технологические требования, система мгновенно реагирует на произошедшее, указывает на проблемы, которые могут быть результатом этого, и определяет, какие изменения надо внести в производственный план, чтобы избежать этих проблем или свести их к минимуму.

Идеология системы ориентирована не “что-то производить и стараться потом продать”, а “стараться производить, то, что продается”. Маркетинг и планирование продаж непосредственно связаны с планированием производства.

Суть концепции MRP II состоит в том, что планирование производства строится на основе некоторого циклического алгоритма, представленного на рисунке 2.

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

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


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

Рис. 2 Алгоритм производственного планирования по стандарту MRP II

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

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

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

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

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

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

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