ERP - системы (Enterprise Resource Planning – планирование ресурсов предприятия

Автор: Пользователь скрыл имя, 20 Февраля 2013 в 18:24, реферат

Описание работы

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

Работа содержит 1 файл

информатика.docx

— 66.79 Кб (Скачать)

 

1. ERP - системы (Enterprise Resource Planning – планирование ресурсов предприятия

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

Концепция ERP сформулирована в 1990 году аналитиком Gartner как видение развития методик MRP II и CIM (англ.), в начале — середине 1990-х годов появилось несколько успешных тиражируемых ERP-систем для крупных организаций, наиболее известные — разработки компаний Baan (нидерл.), Oracle, PeopleSoft, SAP, JD Edwards[3], сформировался рынок услуг по внедрению ERP-систем с участием компаний большой четвёрки, в 2000-е годы произошла консолидация поставщиков, появилось значительное количество ERP-систем для малого и среднего бизнеса, наиболее известными поставщиками которых стали Sage Group и Microsoft[4].

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

Тиражируемость, то есть возможность применить один и тот же программный пакет для разных организаций (возможно, с разными настройками и расширениями), фигурирует как одно из обязательных условий ERP-системы[21]. Одной из причин повсеместного использования тиражируемых ERP-систем вместо разработки на заказ указывается возможность внедрения лучших практик посредством реинжиниринга бизнес-процессов согласно решениям, применённым в ERP-системе[22]. Однако, встречаются и упоминания интегрированных систем, разработанных для отдельной организации на заказ как ERP-систем[23].

Необходимость всеобъемлющего применения ERP-системы в территориально-распределённых организациях требует поддержки  в единой системе множества валют и языков[24]. Более того, необходимость поддерживать несколько организационных единиц (несколько юридических лиц, несколько предприятий), несколько различных планов счетов, учётных политик, различных схем налогообложения в едином экземпляре системы оказывается необходимым условием для применения в холдингах, транснациональных корпорациях.

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

 

2. Автоматизированные  банковские системы (АБС).

Автоматизированная банковская система (АБС) — комплекс программного и технического обеспечения, направленный на автоматизацию банковской деятельности. В соответствии со статьёй 4 Федерального закона «О Центральном банке Российской Федерации (Банке России)», Банк России уполномочен вводить для банков и кредитных организаций особые правила бухгалтерского учета и отчетности, отличающиеся от таких правил для предприятий. Специальный план счетов и большой объём специализированной отчетности перед Банком России делает невозможным использование в банках обычных бухгалтерских систем, не имеющих средств автоматизации получения такой отчетности.

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

Первыми АБС были разработанные в отраслевых НИИ  «Киевский операционный день» и  «Тульский операционный день». На роль старейшего из ныне существующих коммерческих разработчиков АБС претендует компания ПрограмБанк (АБС DOS-Комплекс, переименованная позже в Центавр), организованная в 1989 году. Вслед за ней на рынке появились Инверсия и АСОФТ.

В 1991—1992 на рынок вышел Диасофт с DiasoftBANK, позже переименованной в Diasoft 4x4, в 1993 году — R-Style с RS-Bank-ом, и другие разработчики.

Первые версии таких  продуктов работали в популярных на тот момент операционных системах MS-DOS и Netware с использованием файловых систем типа Clipper и, позже, СУБД Btrieve и имели текстовый интерфейс. Новые версии АБС (в числе первых были Афина и Диасофт 5NT) разрабатывались в графическом интерфейсе с использованием таких СУБД, как Oracle Database, Sybase и в дальнейшем Microsoft SQL Server. Кроме того, ПрограмБанк и ЭСКЕЙП-М использовали в своих продуктах СУБД Caché. В основном переход на новые платформы завершился к 2000 году.

Переломным моментом в развитии рынка стал ввод нового плана счетов бухгалтерского учета  для банков и кредитных организаций  в 1998 году. Если до этого момента  многие банки использовали в качестве АБС собственные разработки, то ввод нового плана счетов вынудил банки  перейти на промышленные АБС. В результате в 1997 году в ходе подготовки к новому плану счетов разработчики АБС испытали подъем продаж, что позволило большинству из них успешно пережить кризис.

По состоянию  на 2006 год в пятерку наиболее популярных разработчиков АБС входили Диасофт, R-Style, ЦФТ, ПрограмБанк, Инверсия, ЮниСАБ. В крупных банках популярностью также пользуются системы Новая Афина и, в меньшей степени, БИС и АБС "Кворум" (по состоянию на 2009 год). Системы иностранного производства не пользуются большой популярностью в силу сложности адаптации к российскому законодательству. Одной из целей функционирования АБС является обработка персональных данных сотрудников и клиентов банка. В таком случае, АБС классифицируется как информационная система персональных данных (ИСПДн) и должна быть защищена в соответствии с требованиями Федерального закона 152-ФЗ «О персональных данных».

В случае принятия в кредитной организации Стандарта Банка России СТО БР ИББС, АБС, реализующие банковские платежные процессы, не рассматриваются как ИСПДн.

Распространённой  проблемой при разработке/приобретении АБС является отсутствие у разработчика лицензии ФСТЭК на разработку средств  защиты информации и лицензии ФСБ  на разработку криптографических средств  защиты информации, что является нарушением Федерального Закона РФ 128-ФЗ «О лицензировании отдельных видов деятельности».

3. Активные  базы данных (Active Databases)

По определению  БД называется активной, если СУБД по отношению  к ней выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД.

Легко видеть, что  основа этой идеи содержалась в языке SQL времени System R. На самом деле, что есть определение триггера или условного воздействия, как не введение в БД правила, в соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то, что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не полностью понятна.

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

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

Вместе с тем, по нашему мнению, гораздо важнее в  практических целях реализовать  в реляционных СУБД аппарат триггеров. Заметим, что в проекте стандарта SQL3 предусматривается существование  языковых средств определения условных воздействий. Их реализация и будет  первым практическим шагом к активным БД (уже появились соответствующие  коммерческие реализации).

 

 

 

 

4. Временные  базы данных (Temporal Databases).

Традиционные базы данных хранят мгновенный снимок объектов модели предметной области, т. е. любое изменение  объекта в базе данных приводит к  тому, что предыдущее состояние объекта  становится недоступным. В отличие  от традиционных систем, ТБД позволяют  сохранить информацию об эволюции объектов предметной области: для любого объекта, который был создан в момент времени tstart и закончил свое существование в момент времени tend, в базе данных будут сохранены все его состояния на временном интервале [tstart,tend]. Таким образом, в ТБД при каждом изменении состояния объекта будет сохраняться запись в базе данных. Уникальный идентификатор такой записи состоит из ключа объекта и временного интервала, на котором данное состояние объекта было актуальным, и имеет следующий вид: {key,[tstart,tend]}, где key -- ключ записи, [tstart,tend] -- временная метка записи. Важной особенностью ТБД является то, что в них возможны запросы не только по ключу, но и по времени. Например, произвести выборку всех состояний объекта с ключом k на временном интервале [t1,t2] или получить состояния всех объектов, которые были актуальны в момент времени t (срез по времени t). Следовательно, методы хранения темпоральных баз данных должны эффективно поддерживать как запросы по ключу, так и по времени. Одной из областей применения ТБД являются системы хранения исторических данных в АСУ ТП. Следует отметить следующие особенности систем исторических баз данных для АСУ ТП:

--

малый размер хранимой записи данных, причем размер самих данных обычно не превышает размер идентификатора записи;

--

большое количество хранимых записей в базе данных;

--

большой размер хранимой базы данных;

--

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

--

возможность удалять и  изменять хранимые записи в базе данных;

--

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

Эти особенности можно  проиллюстрировать следующим примером. Пусть идентификатор записи состоит  из ключа, который является значением  типа short int (2 байта), и временной метки, которая содержит два поля: поле секунды типа long int (4 байта) и поле милисекунды типа short int. Тогда размер идентификатора записи будет 8 байт. Пусть хранимые данные представляют собой плавающие числа типа double (8 байт), тогда размер всей записи составит 16 байт. Если историческая база данных хранит данные за один год, а поток данных в среднем составляет 500 записей в секунду, то количество записей в базе будет около 16*109, а размер базы данных будет около 240 Гб. Высокая производительность системы особенно необходима при записи данных, т. к. поток данных в АСУ ТП может достигать 105 записей в секунду.

 

 

5. Глубинный  анализ данных (Data Mining)

Data Mining (рус. добыча данных, интеллектуальный анализ данных, глубинный анализ данных) — собирательное название, используемое для обозначения совокупности методов обнаружения в данных ранее неизвестных, нетривиальных, практически полезных и доступных интерпретации знаний, необходимых для принятия решений в различных сферах человеческой деятельности. Термин введён Григорием Пятецким-Шапиро в 1989 году.

Английское  словосочетание «Data Mining» пока не имеет устоявшегося перевода на русский язык. При передаче на русском языке используются следующие словосочетания: просев информации, добыча данных, извлечение данных, а, также, интеллектуальный анализ данных. Более полным и точным является словосочетание «обнаружение знаний в базах данных» (knowledge discovering in databases, KDD).

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

Одно  из важнейших назначений методов  Data Mining состоит в наглядном представлении результатов вычислений, что позволяет использовать инструментарий Data Mining людьми, не имеющих специальной математической подготовки. В то же время, применение статистических методов анализа данных требует хорошего владения теорией вероятностей и математической статистикой. Методы Data mining имеет смысл применять только для достаточно больших баз данных. В каждой конкретной области исследований существует свой критерий «великости» базы данных.

Развитие  технологий баз данных сначала привело  к созданию специализированного  языка — языка запросов к базам  данных. Для реляционных баз данных — это язык SQL, который предоставил широкие возможности для создания, изменения и извлечения хранимых данных. Затем возникла необходимость в получении аналитической информации (например, информации о деятельности предприятия за определённый период), и тут оказалось, что традиционные реляционные базы данных, хорошо приспособленные, например, для ведения оперативного учёта (на предприятии), плохо приспособлены для проведения анализа. это привело, в свою очередь, к созданию т.н. «хранилищ данных», сама структура которых наилучшим способом соответствует проведению всестороннего математического анализа. Для задач классификации характерно «обучение с учителем», при котором построение (обучение) модели производится по выборке, содержащей входные и выходные векторы.

Информация о работе ERP - системы (Enterprise Resource Planning – планирование ресурсов предприятия