Интегрирование erp систем на предприятии. Интеграция ERP-системы в логистике: как связать ERP, TMS и WMS? Бесшовная интеграция позволяет

3. Интеграция между подсистемами ERP. Она выражается, главным образом, в регламентированном обмене данными между подсистемами ERP. Нередко эти данные инициируют процессы в других подсистемах. Схема интеграции подсистем показана на рис. 1.4.

Рис. 1.4. Схема интеграции основы КИИСУП

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

A, B, C - подсистемы базовой системы.

A 1 , B 1 , C 1 - подсистемы реальной КИИСУП.

Примечание. Ориентация при построении КИИСУП на управление производственным процессом как единым целым, а не на автоматизацию деятельности отдельных подразделений, занимающихся управлением - это главное требование фактической поддержки целостности системы управления и её наиболее эффективного функционирования. При этом возможно несовпадение функционального наполнения подсистем КИИСУП и функциональных обязанностей в подразделениях - рис. 1.6.

A, B, C - подсистемы, входящие в организационную структуру.

A 1 , B 1 , C 1 - подсистемы КИИСУП.

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

5. Интеграция (комплексирование) в одном решении нескольких разнородных ресурсов. Особенно это проявляется на верхних уровнях планирования, При этом выбор состава ресурсов - за управленцем (рис. 1.7).

6. Интеграция управления всеми стадиями жизненного цикла изделия (рис. 1.8).

Это вид интеграции осуществляется на основе информации по всему жизненному циклу изделия, поддерживаемой подсистемами PLM, PDM.

7. Интеграция управления всеми стадиями производства.

8. Интеграция управления между всеми процессами преобразования ресурсов в продукцию.

9. Интеграция функций управления в виде структуры, включающей функции планирования, учёта, контроля, регулирования, анализа (рис. 1.11).

10. Интеграция КИИСУП с помощью BPMS системы

Фундаментальной особенностью современного этапа развития интеграции является применение BPMS в качестве универсального интегрирующего решения, обеспечивающего новый качественный уровень развития КИИСУП. В результате структура современной КИИСУП приобрела вид, представленный на Рис. 1.12.

На этой схеме представлены как основные современные подсистемы, связанные с развитием направления MRP-ERP-MES, так и подсистема BPMS интеграции и динамической адаптации КИИСУП под требования среды.

Представленные на схеме компоненты КИИСУП имеют следующую расшифровку.

КИАС- корпоративная аналитическая система. Обеспечивает компьютерную поддержку блокам анализа различных контуров управления.Согласно Рис 1.11. в контуре управления состоят блоки учёта, контроля, анализа, регулирования и планирования.

BPMS - business process management system - система управления бизнес процессами. Это интегрирующее средствоядро КИИСУП.

СЭБ/ЭК - системы электронного бизнеса и коммерции. Обеспечивают компьютерную поддержку бизнеса в WEB-сетях.

ERP - enterprise resources planning - планирование ресурсов предприятия.

APS - advanced planning and scheduling - расширенное планирование и диспетчирование.

EAM - enterprise actives management - управление активами предприятия.

CRM - client relationships management - управление взаимоотношениями с клиентами.

CSRP -client synchronized resources planning - синхронизированное с клиентами планирование ресурсов.

СЭД - система электронного документооборота.

ECM - electronic content management - управление электронным контентом.

SCM - supply chains management - управление цепочками поставок.

SRM - supplier relationships management - управление взаимоотношениями с поставщиками.

MES - manufacturing execution system - система оперативного управления производством.

AMM - advanced manufacturing management - расширенное управление производством.

PLM - product lifecycle management - управление жизненным циклом продукции.

PDM - product data management - управление данными о продукции.

CAD - computer aided design - автоматизированное проектирование (САПР).

CAM - computer aided manufacturing - автоматизированное производство.

CAE - computer aided engineering - автоматизированная разработка.

Эти девятнадцать подсистем изучаются в последующих лекциях.

Заключение и выводы

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

Выводы:

Интеграция КИИСУП на базе ERP, MES и других технологий является особенностью и главным достижением современного состояния систем управления предприятиями. Она заключается в согласованном во времени и пространстве выполнении всех элементов процесса управления.

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

Интеграция в системах КИИСУП проявляется многими способами, в том числе в виде объединения в единое целое таких элементов производственных систем и производственных процессов, как:

систем ERP и CAD/CAM/CAE;

ERP, МЕS и других подсистем с внешней средой;

подсистем КИИСУП между собой;

подразделений предприятия;

стадий производственного процесса - от заготовительной до сборочной;

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

элементарных процессов, составляющих единый производственный процесс;

функций управления.

Фундаментальной особенностью современного этапа развития интеграции является применение BPMS в качестве универсального интегрирующего решения, обеспечивающего новый качественный уровень развития КИИСУП.

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

В начале 90-х гг. аналитическая компания Gartner Group ввела новое понятие. Системы класса MRPII в интеграции с модулем финансового планирования FRP (Finance Requirements Planning) получили название системы планирования ресурсов предприятий ERP (E nterprise R esource P lanning ). Это система планирования ресурсов предприятия, предполагающая:

• прогнозирование;
• управление проектами и программами;
• ведение информации о продукции и технологии;
• управление затратами, финансами, кадрами и т.д.

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

В основе ERP-систем лежит принцип создания единого хранилища (репозитария) данных, содержащего всю корпоративную бизнес-информацию:

• финансовую информацию;
• производственные данные;
• данные по персоналу
• и др.

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

В ERP-системах реализованы следующие основные функциональные блоки.

• Планирование продаж и производства. Результатом действия блока является разработка плана производства основных видов продукции.
• Управление спросом. Данный блок предназначен для прогноза будущего спроса на продукцию, определения объема заказов, которые можно предложить клиенту в конкретный момент времени, определения спроса дистрибьюторов, спроса в рамках предприятия и др.
• Укрупненное планирование мощностей. Используется для конкретизации планов производства и определения степени их выполнимости.
• Основной план производства (план-график выпуска продукции). Определяется продукция в конечных единицах (изделиях) со сроками изготовления и количеством.
• Планирование потребностей в материалах. Определяются виды материальных ресурсов (сборных узлов, готовых агрегатов, покупных изделий, исходного сырья, полуфабрикатов и др.) и конкретные сроки их поставки для выполнения плана.
• Спецификация изделий. Определяет состав конечного изделия, материальные ресурсы, необходимые для его изготовления, и др. Фактически спецификация является связующим звеном между основным планом производства и планом потребностей в материалах.
• Планирование потребностей в мощностях. На данном этапе планирования более детально, чем на предыдущих уровнях, определяются производственные мощности.
• Маршрутизация/рабочие центры. С помощью данного блока конкретизируются как производственные мощности различного уровня, так и маршруты, в соответствии с которыми выпускаются изделия.
• Проверка и корректировка цеховых планов по мощностям.
• Управление закупками, запасами, продажами.
• Управление финансами (ведение Главной книги, расчеты с дебиторами и кредиторами, учет основных средств, управление наличными средствами, планирование финансовой деятельности и др.).
• Управление затратами (учет всех затрат предприятия и калькуляция себестоимости готовой продукции или услуг).
• Управление проектами/программами.

Наиболее распространенные в России системы класса ERP:

• SAP R/3
• Oracle Applications
• Галактика
• Парус
• 1С: Предприятие 8
• Dynamics Ax
• Cognos
• Navision Attain и Navision Axapta

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

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

К 2010 г. страны ЕС должны превратиться в наиболее динамично развивающийся, конкурентоспособный регион, являющийся частью глобального информационного Сообщества. Это — стратегическая цель программы "Электронная Европа" (e-Europe), которая должна обеспечить:

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

Интеграция ERP-систем и систем электронной коммерции позволяет реализовать концепцию B4B:

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

Т.е. вопрос стоит не в организации самого производства — он легко решаем с помощью ERP-систем.

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

Система может относиться к классу ERPII, если front-office и back-office представляют собой единое целое.

ERP -2 = ERP + CRM + SCM + PLM

Системы класса CRM:

Расшифровка аббревиатуры CRM (Customer Relationships Management) говорит сама за себя, управление взаимоотношениями с клиентами — задача, которую решает CRM система.

• функциональность продаж(управление контактами, клиентами);
• функциональность управления продажами (прогнозирование, анализ циклов, фиксированная и произвольная отчётность);
• функциональность продаж по телефону;
• управление временем (индивидуальное\групповое);
• поддержка обслуживания клиентов(HelpDesk);
• (управление маркетинговыми компаниями);
• отчёты для высшего руководства;
• интеграция с ERP;
• синхронизация с различными устройствами и системами;
• функциональность электронной торговли;
• мобильные продажи (работа с системой вне офиса).

• увеличение объёма продаж;
• увеличение процента «удачных» сделок;
• увеличение маржи;
• повышение удовлетворённости клиентов;
• снижение административных издержек на продажи и маркетинг.

Прочие преимущества использования систем данного класса:

• Требования клиента не забываются.
• Данные о несостоявшихся и бывших клиентах и о причинах отказов не пропадают.

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

• Дублирование сотрудниками действий друг друга исключаются

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

• Данные о связях клиента сохраняются.

Пример: клиент — член ассоциации… Если ему услуга подошла, почему не предложить ее остальным членам ассоциации.

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

Системы класса SCM:

SCM (supply chain management ) — автоматизированные системы управления цепочками поставок.

Основной задачей является — повышение эффективности логистики. Она позволяет

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

Другие задачи, решаемые системами класса SCM:

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

Система класса SCM может быть использована:

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

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

Другие классы систем поддержки производственно-коммерческого цикла:

• PLM (Product Lifecycle Management) — управление жизненным циклом продуктов;
• PDM (Product Data Management) — системы управления производственными данными.
• APS (Advanced Planning/Scheduling) — развитие системы планирования; расширенное планирование производственных заданий.

Совокупный объем продаж тяжелого софта (ERP и ERP-подобных систем) и сопутствующего консалтинга на этапе внедрения превысил 90 млн. USD-100 млн. USD (по различным оценкам). 1/3 этого объема приходится на продажу лицензий

Вопрос читателя: В случае использования интегрированного решения СЭД+ЕRP действительно ли есть риск невозможности доработки одной системы из-за ограниченных возможностей другой? Тогда какой смысл внедрения и интеграции, если при этом нельзя использовать полный функционал?

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

Например, из ERP-системы можно будет обратиться к образам документов, хранимых в ECM. Или при исполнении бизнес-процесса получить данные, которые хранятся в ERP-системе.

Интеграция может быть налажена между отдельными системами, а в случае если таким образом интегрируются более двух систем, шлюзов может быть несколько. Другой вариант – использование универсальной корпоративной шины сервисов данных и управления (ESB). Если система не поддерживает расширения, невозможно произвести доработку, загрузить, выгрузить или получить прямой доступ к данным – интеграция с ней будет невозможна. Обычно, это legacy-системы (буквально «доставшиеся в наследство») - доживающие свой век продукты, которые уже не развиваются, а только эксплуатируются. Чаще всего приложение можно доработать или получить доступ к данным: таким образом обеспечивается возможность интеграции. Разумеется, оценивая возможность интеграции систем, нужно оценить и соотнести все выгоды и затраты.

Задача интеграции ERP и ECM систем не возникает на пустом месте - это требуется в процессе автоматизации определенных бизнес-процессов компании .

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

Вариантов взаимодействия систем существует масса, приведу примеры лишь двух из них.

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

Например, при обработке накладной в ERP-системе требуется доступ к ее скан-образу, который может содержать рукописные правки и отметки. С такой задачей постоянно сталкиваются дистрибьюторы, которые организуют массовый развоз товаров по торговым точкам. В случаи выявления брака, недостачи или пересортицы соответствующие отметки производятся в бумажной накладной. Если обработка накладных централизована и территориально производится в другом месте, выходом из ситуации может стать потоковое сканирование накладных в ECM-систему. Интеграция систем позволит связать данные в ERP-системе с образом документа, который хранится в ECM-системе. Бухгалтер, обрабатывающий накладные, получает доступ к необходимой информации (отметки и исправления) и сможет скорректировать данные в ERP-системе.

Другой сценарий интеграции систем в чем-то является зеркальным первому – это организация доступа к данным ERP-системы из ECM-приложения.

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

В приведенных сценариях ECM-система может выступать и как техническое средство управления бизнес-процессами, то есть взять на себя функции BPM (Business Process Management).

BPM-движок, или механизм оркестровки бизнес-процессами, у нее уже есть: необходимо будет разработать коннекторы (механизмы интеграции) к другим системам. Например, коннектор к выбранной ERP-системе.

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

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

Разумеется, полет мысли автоматизаторов бизнес-процессов ограничивается интеграционными возможностями систем. Систем, с которыми невозможна никакая интеграция, становится все меньше – обычно, это уже упомянутые нами выше legacy-системы

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

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

Со временем OLAP-системы стали реальной угрозой рынку ERP. Заказчик зачастую предпочитал покупать аналитические приложения в качестве интеграционного инструмента для своей “лоскутной” автоматизации. Почувствовав опасную тенденцию, большинство производителей ERP-систем на сегодняшний день либо разработали свои собственные OLAP-приложения, либо тесно интегрировались с зарекомендовавшими себя производителями OLAP-ов. К слову сказать, попытки первых самостоятельно изобретать велосипед не привели к ожидаемому успеху. Любой “наскоро сколоченный” OLAP все равно уступал по функциональным возможностям промышленным системам анализа и слабо справлялся с теми многоаспектными данными, которые способны генерировать высококлассные ERP-системы.

Казалось бы, ответ на вопрос “Из каких компонент должна состоять полноценная Информационная Система Управления Предприятием?” достаточно очевиден. ERP и OLAP. Однако есть и здесь одно “но”. Как известно, три классические фазы управления – Планирование, Учет и Контроль – в некоторых задачах пересекаются настолько тесно, что становится трудно отделить одно от другого. Следовательно, полноценная автоматизация таких задач с помощью только средств учета или только средств анализа невозможна. Возьмем в качестве примера функцию Финансового планирования. Для реализации этой задачи необходимы, как минимум, следующие данные по кредиторской задолженности:

Счета к оплате

Открытые позиции (задолженность в разрезе поставщиков)

Контракты на поставку

Заказы на поставку

Платежи (текущие и плановые)

Бюджетные статьи

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

Многие финансовые аналитики для решения таких задач используют широко известныйExcel. Однако эта популярная программа годится для одного пользователя. И то, если этот пользователь достаточно искушен в вопросах связи Excel с внешними приложениями. В нашем же случае речь идет о слаженном взаимодействии целой группы сотрудников финансовых служб, каждый из которых имеет свои собственные полномочия по работе с графиком платежей. Добавим сюда еще и менеджеров – финансовых контролеров и членов бюджетного комитета, контролирующих работу своих подчиненных. Получается, что для автоматизации функций аналогичных финансовому планированию необходимо иметь использовать такое Приложение, которое обладает эргономичностью популярных электронных таблиц, “транзакционностью” ERP-систем и аналитической мощью OLAP-ов.

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

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

Международная компания IDC, специализирующаяся на независимом мониторинге рынка программного обеспечения, объединила такие приложения в новое семейство – BPM (BusinessPerformanceManagement , т.е. Управление Эффективностью Бизнеса).

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

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

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

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

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

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

Я и моя команда работают над системой ERP, имеют много модулей (HR, Accounting и т.д.)

Проблема, с которой мы сталкиваемся, состоит в том, что между двумя модулями (HR, Accounting), такими как сотрудники, есть несколько общих объектов

Сотрудники системы HR имеют много деталей, таких как:

Personal Information , Visa Info , Report To , Sources , Training , Etc

Сотрудники в области бухгалтерского учета имеют немного информации

Personal Information , Bank Account , Employee Account (That it)

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

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

Что мне нужно, когда я определяю нового сотрудника в модуле HR, чтобы позволить модулю учета чувствовать это изменение и что происходит в обоих модулях, которые они должны иметь с одним и тем же объектом?

Учтите, что этот сотрудник связан с другими организациями, такими как компания, с которой он связан, и этот субъект компании отличается в обоих модулях (например, он имеет много деталей в HR-модуле, но в компании только для бухгалтерского учета есть некоторые ветки под ним)

Примечание. Каждый модуль имеет отдельную базу данных (не хотел, чтобы увеличить базу данных в автономной версии)

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

Слишком поздно, и мы должны проектировать его с самого начала как общие объекты?

И если я использовал общие сущности, которые означают, что я должен сделать общую бизнес-логику и уровень доступа к данным?

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

Технологии: Asp.net + Mysql

2 ответа

Не делайте ошибки при соединении всех ваших модулей на уровне базы данных.

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

Подумайте, как объекты, не решая, как они будут развернуты. Вы можете захотеть, чтобы это был объект в памяти; это может быть распределенный компонент, который вы выбираете для удаленного использования SOAP или REST или CORBA или XML через HTTP. Но дело в том, для разложения проблемы на компоненты без совместного использования схемы.

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

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

Просто любопытно - зачем вы пишете ERP-систему с нуля, когда доступно так много коммерческих? Они дороги и сложны, но так пишут ваши собственные. Какова была компромиссная дискуссия?