Слишком сложно? Тогда запросите консультацию специалиста!
Наша компания занимается тем, что помогает студентам выполнять различные учебные работы на заказ. Вы можете ознакомиться с перечнем выполняемых работ, а так же с их стоимостью на странице с ценами.
Одна и та же функциональная архитектура, в зависимости от требуемой мощности системы, может быть реализована в различных типах технологических архитектур. Обычно это клиент-серверная архитектура, но она может иметь различный вид. (См. ниже).
Рис. - Функциональная архитектура решения Галактика НИОКР
В основе ERP систем лежит принцип создания единого хранилища данных, содержащего всю корпоративную бизнес-информацию и обеспечивающего одновременный доступ к ней любого необходимого числа сотрудников предприятия, наделенных соответствующими полномочиями. Декларируется, что это должно не только повысить эффективность производственной деятельности предприятия, но и сократить внутренние информационные потоки, уменьшив тем самым затраты на их обеспечение.
Применение архитектуры клиент-сервер для информационных систем. Распределенные клиент-серверные системы для автоматизации планирования ресурсов предприятия
В данной архитектуре одновременно используется вертикальное и горизонтальное распределение.
В системе используются тонкие клиенты (Thin Client).
Серверы баз данных (Database Server) и серверы приложений (Application Server) – распределены.
Вертикальное: тонкий клиент - сервер приложений - сервер БД).
Горизонтальное: серверы баз данных (Database Server) и серверы приложений (Application Server) распределены (на n-экземпляров, связанных между собой; между ними потом распределяются запросы от клиентов).
Каждый экземпляр СП (сервера приложений) может выполнять либо однотипные (с другими СП) функции, либо обладает отличным от других функционалом (функциональное распределение). Экземпляры Сервера БД также могут управлять базами с одинаковой информацией, либо с различной. Если все однотипно, то обычно это сделано для того, чтобы повысить мощность и быстродействие системы за счет распределения нагрузки (обслуживание потока запросов клиентов) по нескольким машинам. Управление распределением запросов по машинам (т.е. по серверам приложений и серверам БД) может осуществляться различными способами. Исторически первый способ – использование менеджеров транзакций.
Горизонтальное распределение часто определяется как кластеризация (Cluster – «гроздь»).
ERP-система (англ. Enterprise Resource Planning System — Система планирования ресурсов предприятия) — это интегрированная система на базе ИТ для управления внутренними и внешними ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие ресурсы). Цель системы — содействие потокам информации между всеми хозяйственными подразделениями (бизнес-функциями) внутри предприятия и информационная поддержка связей с другими предприятиями. Построенная, как правило, на централизованной базе данных, ERP-система формирует стандартизованное единое информационное пространство предприятия.
Набор основных функций ERP систем:
- ведение конструкторских и технологических спецификаций, определяющих состав производимых изделий, а также материальные ресурсы и операции, необходимые для его изготовления;
- формирование планов продаж и производства;
- планирование потребностей в материалах и комплектующих, сроков и объемов поставок для выполнения плана производства продукции;
- управление запасами и закупками: ведение договоров, реализация централизованных закупок, обеспечение учета и оптимизации складских и цеховых запасов;
- планирование производственных мощностей от укрупненного планирования до использования отдельных станков и оборудования;
- оперативное управление финансами, включая составление финансового плана и осуществление контроля его исполнения, финансовый и управленческий учет;
- управления проектами, включая планирование этапов и ресурсов, необходимых для их реализации.
Пример ERP-системы:
Решение Управление НИОКР (научно-исследовательскими и опытно-конструкторскими работами на предприятии) построено на базе системы Галактика ERP. Функциональная архитектура решения включает модуль Управление НИОКР и связанные с ним по бизнес-процессу другие модули системы. Ниже показана общая функциональная архитектура системы (на ней никакого клиент-сервера еще не видно):
Множество действующих в экономике предприятий можно разбить на следующие основные категории (по численности работающих): большие корпорации (более 10 тыс. сотрудников); средние корпорации - от 1000 до 10 тыс. человек; средние (от 100 до 1000) и малые предприятия (до 100 сотрудников). Большинству этих предприятий, независимо от их размеров, требуется комплексная система управления, которая охватывала бы все аспекты их деятельности: внутренний учет, планирование и управление, взаимоотношения с клиентами, поставщиками и партнерами. Иными словами, это должна быть система, соответствующая концепции ERP II.
Наряду с классификацией предприятий существует и интуитивное деление ERP-систем - на тяжелые, средние и легкие. Исторически тяжелые ERP-системы в основном применялись в больших корпорациях, средние - в средних корпорациях, а легкие - на средних предприятиях. Малые предприятия не использовали ERP-системы, поскольку для них это было дорого, в основном ограничиваясь стандартными системами автоматизации офисной деятельности и системами, автоматизирующими отдельные бизнес-процессы.
Однако ситуация постепенно меняется. Общее развитие технологии и повышение уровня компьютеризации приводят к тому, что малые предприятия начали использовать для создания систем управления легкие ERP-системы, средние ERP-системы в ряде случаев стали применяться на средних предприятиях, а тяжелые - в средних корпорациях.
Определяя классы ERP-систем на основе собственных свойств систем, все различия можно свести к следующим основным аспектам: функциональность и масштабируемость технологической платформы. Другие характеристики, такие, как возможность интеграции с другими программными средствами и модернизации стандартно поставляемой функциональности, практически не оказывают влияния на принадлежность системы к тому или иному классу, а скорее характеризуют соответствие систем современным требованиям.
Масштабируемость технологической платформы
Будем рассматривать только ERP-системы, имеющие трех- или многоуровневую архитектуру.
Число пользователей, которые могут одновременно работать в ERP-системе зависит от программно-аппаратной платформы: конфигурации серверов, общей конфигурации сети, используемых ОС и СУБД, средств промежуточного слоя и т. д. Это все внешние факторы, которые лежат вне ERP-системы и могут меняться в ходе ее инсталляции и работы. Внутренними факторами, определяющими максимальное число одновременно работающих пользователей, будут размеры базы данных и особенности бизнес-процессов предприятия. Но основная характеристика ERP-системы, определяющая максимальное число одновременно работающих пользователей, - это ее технологическая архитектура.
Максимальное число одновременно работающих пользователей в большинстве случаев можно считать наиболее жестким ограничением применимости той или иной системы на конкретном предприятии. Недостающую функциональность можно дописать, можно применить специализированное отраслевое решение, а если его нет, его можно разработать; но если система поддерживает работу не более ста пользователей, а нужно, чтобы одновременно работала тысяча, никакое увеличение мощности серверов не поможет. От системы придется отказаться.
Легкая ERP-система - система, способная использовать только один сервер БД и только один сервер приложений. Технологическая архитектура такой системы представлена на рисунке. Все запросы пользователей, поступающие с рабочих станций, обрабатываются сервером приложений, который взаимодействует с сервером баз данных.
(Дальше по тексту идут рисунки, где сервера приложений не подписаны – где встречается рисунок компьютера – это означает, что это сервер приложений. Сервер баз данных обозначен похоже, но как синяя стойка с ячейками – не перепутать!)
Из ERP-систем этого класса на российском рынке наиболее известны "Управление производственным предприятием" на платформе "1С:Предприятие 8.0" и Microsoft Business Solutions-Navision с использованием Microsoft SQL Server Option.
ERP-система такой архитектуры в реальных условиях эксплуатации способна поддерживать одновременную работу до 100 пользователей. По мере приближения к этому пределу увеличение числа процессоров в серверах и их мощности не обеспечивает соответствующего прироста числа пользователей. Возникает эффект насыщения: каждое последующее увеличение числа пользователей требует намного большего прироста ресурсов.
Комплекс легких ERP-систем
Для того чтобы обслуживать большее число одновременно работающих пользователей, используются комплексы запускаемых параллельно легких ERP-систем, каждая из которых работает со своей группой пользователей. Например, если компания состоит из нескольких юридических лиц или территориально удаленных подразделений, то в каждом из них устанавливается свой экземпляр легкой ERP-системы, и все пользователи этого юридического лица или удаленного подразделения работают только со своим экземпляром системы. Экземпляр, установленный в головном офисе, назначается центральной системой, и в соответствии с некоторым расписанием организуется обмен данными между центральной системой и периферийными. Пример технологической архитектуры комплекса легких систем, включающего центральную систему и две периферийные: .
|
(связи – это обмен данными между БД, реализуемый любым доступным способом)
Помимо увеличения производительности и максимального числа обслуживаемых пользователей, разделение единой технической среды на несколько частей и использование нескольких приложений вместо одного может иметь и другие положительные эффекты. Так, системы, используемые на отдельных объектах автоматизации (на отдельных предприятиях или в их обособленных подразделениях), можно адаптировать к специфике этих объектов. Если объекты территориально удалены друг от друга, распределение обработки информации приведет к снижению трафика и соответственно платы за него. Вынос значительной части обработки данных на периферийные объекты повысит надежность и живучесть системы в центральном офисе, обеспечит относительную независимость систем. В случае перехода на новое поколение систем этот процесс может осуществляться поэтапно, а не во всех подразделениях и дочерних предприятиях одновременно. Кроме того, использование нескольких систем может улучшить качество администрирования и поддержки периферийных систем за счет устранения барьеров, обусловленных разностью часовых поясов, или языковых барьеров для объектов, расположенных в разных странах.
Использование комплекса ERP-систем целесообразно только тогда, когда выполняются условия:
· не требуется доступ к актуальным данным всех объектов в режиме online;
· все периферийные подразделения занимаются однотипной деятельностью и используют единые стандарты учета для информации, передаваемой в центральный офис;
· на периферийных объектах используется не вся функциональность ERP-системы, а только отдельные функциональные модули (не должно возникать ситуации, когда каждая система работает независимо и теряется возможность управления предприятием как единой целостной системой).
Например, сеть магазинов или предприятий сферы обслуживания, каждое из которых имеет несколько десятков рабочих мест, естественным образом автоматизируется при помощи комплекса легких систем. Деятельность подразделений в этом случае однородна или почти однородна. Каждое из них выполняет ограниченный набор функций и не реализует сложных производственных процессов. В связи с этим можно определить единые описания форматов данных, передаваемых между центральным офисом и удаленным подразделением.
Если же сформулированные условия не выполняются (нарушается хотя бы одно из них), например:
· периферийные объекты неоднородны - универсам, центр автосервиса, ресторан и гостиница;
· руководство холдинга хочет оперативно в режиме online получать информацию о деятельности своих подразделений;
· руководство холдинга хочет получать разнородную и не поддающуюся полной предварительной регламентации информацию - данные об обеспеченности ресторана продуктами, перечень работ, выполненных за некий период автосервисом в разрезе марок автомобилей и т. д.;
· хотя бы в одном из подразделений существует сложный комплекс бизнес-процессов, требующий развитой функциональности управления и нуждающийся в постоянном контроле и планировании со стороны руководства холдинга;
тогда систему управления таким холдингом лучше создавать на основе средней ERP-системы.
Средняя ERP-система
Определим среднюю ERP-систему как систему, использующую только один сервер баз данных и произвольное число серверов приложений. Известный пример такой системы - Microsoft Business Solutions-Axapta. Два варианта технологической архитектуры систем управления, построенных на основе средней ERP-системы с использованием трех серверов приложений, представлены на рисунке:
| 
|
| Рис.3 | Рис.4 |
(Здесь связи прямыми линиями – это непосредственное взаимодействие серверов с серверами, клиентов с серверами (по доступным коммуникациям сети с использованием доступных интерфейсов, протоколов и т.д., кривые линии – просто перезапись программ между серверами с целью пополнения репозиториев (библиотек) прикладных программ). Ниже на рисунках смысл связей такой же, как здесь и на предыдущем рисунке.
Вариант архитектуры средней системы, представленный на рис. 3, как раз и реализован в Microsoft Axapta. В обоих вариантах с одним сервером базы данных работают несколько серверов приложений, а различие между ними состоит в организации библиотеки приложений, содержащей актуальные версии всех приложений ERP-системы. В системе с централизованной библиотекой приложений эта библиотека выделена из состава серверов приложений, и все серверы используют единую библиотеку. Во втором случае каждый сервер приложений использует собственную библиотеку приложений. Такая архитектура предполагает наличие в системе развитых средств обмена настройками и программными объектами между библиотеками приложений. Первый вариант архитектуры требует меньших затрат при эксплуатации, однако второй обеспечивает большую масштабируемость системы.
На начальном этапе работы можно использовать только один сервер приложений, а затем постепенно наращивать их число. В случае одного сервера приложений максимальное количество одновременно работающих пользователей будет примерно тем же, что и для легкой системы. При подключении новых пользователей число серверов приложений можно увеличивать. В максимальных конфигурациях технических средств, содержащих несколько десятков серверов приложений, число пользователей может достигать нескольких тысяч.
Возможность одновременного подключения нескольких серверов приложений существенно усложняет технологическую платформу средней ERP-системы. Одна из основных проблем состоит в том, что серверы приложений кэшируют объекты базы данных. В случае изменения каких-то данных в кэше одного из серверов необходимо сразу исключить измененные объекты из кэш-памяти других серверов. Это важная проблема, имеющая более общий характер: звучит как «Контроль когерентности данных в нескольких кэш» или Cache Coherency Check (проверить синтаксис!). Имеет место, например, в многопроцессорных системах с общей памятью и даже в многоядерных процессорах.
Усложнение технологической платформы средних систем по сравнению с легкими сопровождается и более развитой функциональностью. Это обусловлено тем, что бизнес-процессы средней корпорации более сложны и соответственно требуют развитой бизнес-логики системы и поддержки большего числа одновременно работающих пользователей. Иными словами, в целом при переходе к следующему классу сохраняется некоторая пропорциональность между платформой и функциональными компонентами ERP-системы.
Комплексы на основе средней ERP-системы
Так же, как для легких, для средних систем справедливо положение, что увеличение числа одновременно работающих пользователей за счет наращивания ресурсов имеет свой предел, обусловленный лежащими в основе системы архитектурными решениями. При достижении этого предела дальнейшее увеличение числа серверов приложений, повышение мощности процессоров, объема памяти, пропускной способности каналов ведет к очень незначительным улучшениям.
При наличии нескольких территориально удаленных объектов система управления предприятием может быть организована как комплекс, состоящий из средней ERP-системы и нескольких легких. Пример технологической архитектуры комплекса, включающего среднюю систему в центральном офисе и две периферийные легкие системы, приведен на рис. 5.
|
| Рис. 5. Архитектура комплекса из одной средней ERP-системы с централизованной библиотекой приложений и двух легких (обозначения см. на рис. 1). |
Комплекс из одной средней и нескольких легких систем по сравнению с единственной средней системой имеет те же преимущества и ограничения, что и комплекс легких систем по сравнению с одной такой системой. Разница только в том, что использование средней системы позволяет увеличить число рабочих мест и расширить функциональность в центральном офисе. Существенным положительным эффектом от создания такого комплекса по сравнению с единой средней системой будет также более низкая удельная стоимость рабочих мест на периферийных объектах из-за меньшей стоимости лицензий и подписки на обновление легких систем.
Если легкие ERP-системы на периферийных объектах не обеспечивают поддержку необходимого числа рабочих мест, можно создать комплекс из средних систем. Технологическая архитектура такого комплекса, как и в случаях рассмотренных выше комплексов, выстраивается путем объединения технологических архитектур образующих этот комплекс систем. Число уровней иерархии систем в комплексе может быть больше двух за счет создания подсистем управления по территориальному, отраслевому или иному признаку.
Использование средних систем на нижних уровнях иерархии может также обосновываться недостаточной функциональностью легких ERP-систем для управления периферийными объектами. Однако применение средних систем на объектах, требующих автоматизации одного-двух десятков рабочих мест, не оправдывает себя по затратам. В большинстве случаев целесообразно не переходить к средним системам, а использовать на периферийных объектах легкие системы совместно с отраслевыми решениями, реализующими необходимую специфику бизнес-процессов. И только если несколько необходимых функциональных модулей вообще отсутствуют в легких системах, может оказаться выгодным применять на периферийных объектах средние ERP-системы.
В тех случаях, когда одна средняя ERP-система не может обеспечить работу необходимого числа пользователей, а их комплекс не подходит по причине уже рассмотренных нами ограничений на применение комплексов, для автоматизации управления предприятием лучше использовать тяжелую ERP-систему.
Тяжелая ERP-система
Определим тяжелую ERP-систему как систему, использующую произвольное число серверов баз данных и обеспечивающую работу произвольного числа серверов приложений с каждым сервером баз данных. Наиболее распространенный пример тяжелой системы - mySAP Business Suite. Два варианта технологической архитектуры тяжелой ERP-системы в составе четырех серверов приложений и четырех серверов баз данных представлены на рисунках:
|
|
Для работы с несколькими независимыми серверами баз данных тяжелая система должна иметь внутри себя описание структуры баз, расположенных на каждом сервере, чтобы строить запросы к ним, исходя из необходимости обработки конкретных данных. Иными словами, тяжелая система по определению включает в себя как один из компонентов систему управления распределенной БД, для работы которой используются серверы СУБД.
Как и в случае средних систем, рассматриваемые варианты технологической архитектуры различаются способом организации библиотеки приложений. В варианте на рис. 6 для библиотеки выделяются отдельные серверы, каждый из которых может использоваться несколькими серверами приложений, что обеспечивает сокращение затрат на сопровождение системы из большого числа серверов приложений, объединенных в компактные группы. В варианте на рис. 7 каждый сервер приложений работает с собственной библиотекой приложений, обеспечивается независимость серверов приложений и высокая масштабируемость системы. Этот вариант реализован в mySAP Business Suite.
Наличие внутренней встроенной СУБД значительно усложняет ERP-систему, однако обеспечивает ее масштабирование до десятков тысяч одновременно работающих пользователей. Для больших корпораций, состоящих из десятков, а иногда и сотен территориально удаленных предприятий, использование тяжелой системы иногда оказывается единственной возможностью обеспечить эффективное управление. Однако преимущества, получаемые при использовании тяжелой системы, имеют оборотную сторону в виде высоких затрат на ее приобретение, внедрение и сопровождение, а также на оплату трафика, образующегося при работе с территориально удаленными серверами.
Один из способов снижения затрат на трафик - моделирование средствами тяжелой системы технологической архитектуры комплекса средних систем за счет пообъектного размещения серверов (рис. 8). В этом случае все данные локального подразделения (предприятия, группы предприятий) размещаются на сервере баз данных, находящемся на территории или в непосредственной близости от этого объекта. Там же располагаются все серверы СУБД и серверы приложений, обслуживающие пользователей этого объекта. В итоге трафик между территориально удаленными объектами образуется только при обработке запросов, поступающих из холдинга, или при взаимодействии между объектами. В представленном на рис. 8 варианте технологической архитектуры каждый сервер работает с собственной библиотекой приложений, а в целом вся система распределена по трем региональным сетям.
|
| Рис. 8. Архитектура тяжелой ERP-системы с пообъектным размещением серверов |
Платой за сокращение трафика станет в этом случае децентрализация вычислительных мощностей и увеличение затрат на обслуживание технических средств. Поэтому выбор оптимального варианта требует предварительных расчетов.
Еще один способ снижения затрат на эксплуатацию тяжелой системы - организация комплекса из тяжелой системы и нескольких средних. Тяжелая система охватывает те объекты, данные о которых должны быть доступны в режиме online; объекты, взаимодействие с которыми не поддается полной предварительной регламентации; и объекты с большим числом рабочих мест, превышающим возможности средней системы. На остальных объектах устанавливаются средние системы. Комплекс на основе тяжелой системы, как и в случае средней системы, может иметь более двух уровней иерархии, а на нижних ее уровнях можно использовать легкие ERP-системы.
Конечно, для полного рассмотрения вопроса 'Легкие, средние и тяжелые ERP-системы', приведенной информации не достаточно, однако чтобы понять основы, её должно хватить. Если вы изучаете эту тему, с целью выполнения задания заданного преподавателем, вы можете обратится за консультацией в нашу компанию. В нашей команде работает большой состав специалистов, которые разбираются в изучаемом вами вопросе на экспертном уровне.
