Академический Документы
Профессиональный Документы
Культура Документы
Table of Contents
Preface
1 Introduction
1.1 ERP Introduction
1.2 How does an ERP journey begin?
1.3 How does the ERP operation work?
2 Business & Processes
2.1 ERP Operations Introduction
2.2 SAP Operations Introduction
2.3 The SD Module
Sales Order Structure
The Sales & Distribution Process (Order-to-Cash)
SD Enterprise Integration (Advanced Topics)
2.4 The MM Module
Material Management Overview
Centralized / Decentralized Procurement
Purchase Order Structure
The Procurement Process (Procure-to-Pay)
MM Enterprise Integration (Advanced Topics)
2.5 The PP Module
Production Planning Overview
The Production Process (Plan-to-Product)
Production Order Structure
The Production Execution Process
PP Enterprise Integration (Advanced Topics)
2.6 The PS Module
Project System Overview
Project System Structure
The Project System Process (Engineer-to-Order)
The Project System Process (Build-to-Asset)
The Project System Process (Enterprise Asset)
PS Enterprise Integration (Advanced Topics)
2.7 The FI Module
Finance Overview
Finance Structure
The Finance Reporting Process (Record-to-Report)
Formally, ERP belongs to a class of business systems that brings together enterprise information,
primarily financial, logistical and human resource related, in order to support of enterprise level
reporting planning and operations. ERP are typically modular in nature, as it plays a central role of
integrating major business lines, such as sales, purchasing, manufacturing, finance, etc. The
benefits of ERP are well-documented by Shang & Seddon’s ERP Benefits Framework (2002); the
list includes reduced cost, reduced cycle time, improved decision-making, improved customer
services, improved external/internal collaboration, empowered employee, learning facilitation,
better morale.
Having a centralized ERP presupposes that processes and data are consistently defined. The
challenge of ERP is not in the system application itself but rather on the level of clarity the
organization has of its own business processes. ERP implementation can fail either due to the
organizations having conflicting processes that no ERP application can support, or the ERP itself is
not flexible to handle the complex business operations – it is often more of the former than the
latter.
SAP provides has two primary ERP products, namely: the heavyweight SAP ECC (SAP ERP
Central Component), and a lighter-weight SAP B1 (Business One). Oracle has at least 5 ERP
solutions, namely: EBS (eBusiness Suite), Siebel, PeopleSoft, JD Edwards and NetSuite. Microsoft
has one primary ERP product, MS Dynamics AX (aka MS Dynamics 365F&O). Following the Big 3
is Infor; it has acquired 40 softwares (of which a significant number are business systems & ERP)
since its 2002 founding. There are too many Infor ERP to be listed.
SAP will be used as the referenced ERP when we are in specific discussions, whilst Oracle will be
used as a supplementary comparison where possible.
SAP ECC has very comprehensive modules to cater for enterprise needs. For logistics, it has
Sales and Distribution (SD), Material Management (MM), Production Planning (PP), Quality
Management (QM), Project Systems (PS), Plant Maintenance (PM). For finance, it has Financial
Accounting (FI), Management Accounting (CO). For human resource, it has submodules like
Personnel Administration, Benefits Administration, Payroll, and Performance Management. In
addition, extension modules provide functionalities such TM (Transport Management), WM
(Warehouse Management), Treasury (TRM), and Financial Supply Chain (FSCM).
With the advancement of technology, in-memory technologies also made its way to ERP. Specific
to SAP, the in-memory database is known as HANA® database (technical details at SAP website).
HANA is a high performing native database created and used by SAP®; it allows SAP ERP
applications to push application level processing into the database level - yielding even better
performance and integration. S/4 HANA (aka SAP Business Suite for SAP HANA) the next
generation of ERP is made possible with HANA.
S/4 HANA can be deployed in the cloud or installed on-premises. The primary advantages of cloud
solution are having the infrastructure support taken care by the cloud provider and the solution can
be scaled for optimal usage. There are various cloud options, offering various degrees of
customizations. The more interesting part of all these is, the third option – hybrid deployment. For
instance, if the organization is deep into customizing its logistical modules but generic in its human
resource processes, they can opt for on-premises logistics and cloud human resource. Another
example will be individual on-premises subsidiaries’ ERP (SAP or non-SAP) linking back to the HQ
Central Finance cloud solution.
The ERP trend now is with in-memory and cloud computing. SAP, Oracle and other major ERP
suppliers are supporting this vision with various offerings.
We are not quite done yet before having some comparisons with Oracle - the other big player in
the ERP space.
The difference between the two ERP vendors (SAP, Oracle) is at both the marketing level and
product level. In Oracle, there is a large basket of matured ERP products, giving different varieties
to the customers. In SAP, attention is channeled into refining a smaller basket of ERP products (i.e.
ECC and B1), while having more capacity to take-on deeper extended functionalities.
All in all, the specific operating of each ERP products may differ but they are serving a common
market that has common requirements. In this sense, it is more important to know what are the
business requirements, rather than the exact steps to execute an operation.
For a trading business model with stocked goods, simple inventory issues will be the process for
supplying. For a trading business with non-stock goods, purchase orders will be raised to start the
Procure-to-Pay process.
For a manufacturing business, the Plan-to-Product process is used. The process comprises of the
planning phase and the execution phase. Planning decision depends on whether it is using Make-
to-Stock or Make-to-Order scenario. During execution phase, production orders will be raised to
start the manufacturing steps. In additional, goods that can have preset variation requirements
need to be processed via Configure-to-Order scenario.
For a manufacturing business with complex product (for instance, pre-studies are required), a
project step is needed prior to manufacturing. This flow is termed as the Engineer-to-Order
process.
For complex product that does not need manufacturing, the Build-to-Asset (aka Built-to-Order)
process can be used; a project will be setup for detailed tracking, subsequently resulting in a final
asset that may be sold.
Financial accounting and management accounting will be managed through the Record-to-Report
and Controlling process, respectively; whilst the human resource requirements will be managed
though the Hire-to-Retire process.
In summary, ERP empowers the enterprise to operate with seamless dataflow and business
insights. Enterprise profitability and performance can tracked and presented, with transactional
details that are readily available across the sub-ledgers and sub-modules.
For Cost Analysis, controlling users do use the CO functionalities within their ERP, sometime
supplementary cost data are extracted elsewhere. If the ERP is SAP ECC, then SAP CO mostly
likely will be used, due to its intrinsic level of integration. Almost nobody with SAP ECC, replaces
its SAP CO module and takes up something else – that is unimaginable.
For Budgeting, users typically use specialized budgeting application(s) that differ from their ERP.
This is because budgeting occurs at various levels (i.e. group, enterprise, operational) and multiple
timeframes (i.e. long-term, short-term, micro-term). SAP do offers SAP ECC Budgeting sub-
modules (Investment Management, Project Systems, Internal Order, and Cost Center) and SAP
BPC to support ERP level Budgeting. SAP BPC is recommended if the enterprise is having both
SAP and non-SAP systems as ERP.
In SAP CO, there are 3 primary sub-modules, namely: Overhead Cost Management (CO-OM),
Product Costing (CO-PC), and Profitability Analysis (CO-PA). SAP PS can be used as part of
controlling; whilst BPC is an alternate budgeting tool.
The Vanilla version revolves along FI and is based on GL accounts (cost elements). Basically, it
enriches FI postings with key information such as Customers, Products, Market Segments, Sales
Order number, Purchase Order number etc. – while having fully reconcilable figures with SAP FI. It
provides cost information at the total level (GL accounts/cost elements), without any COGS
breakdown or Variance breakdown. Typically this is sufficient for non-manufacturing organization.
For enterprise with complex requirements requesting details on the COGS and Variances
breakdown; the Costing COPA, provides up to 120 freely-definable value fields to account for the
detailed requirement of cost/revenue breakdown – while still allowing up to 50 analysis fields (aka
dimension/characteristics). In addition, it also allows early posting of Sales Order entries prior to
Billing into Costing COPA for Order Intake Analysis. The actual data in Costing COPA can be fed
into production for Sales & Operations Planning (aka SOP).
BPC layout is well suited for customized planning process. For instance, if the budget cycle starts
in September with remaining 3 months (October, November, December) as forecast and next 12
month (January to December) as planned – the whole 15-month cycle can all be achieved in one
excel layout. As BPC leverages on the processing power of SAP BW / HANA, it can offer real-time
what-if analysis.
CRM suites enable enterprises with capabilities such as extensive pricing, quotation, service and
analytics to handle varying upstream demand. The potential CRM can be SAP Hybris suite or
Salesforce. In addition, CRM-related Billing solutions are able to track and bill large numbers of
customers, while reducing posting footprints into ERP. Likewise, in financial institutes, large
number of financial assets can be processed in SAP FAM (Financial Asset Sub-ledger) before
having the net balances sent into ERP. SRM solutions (such as SAP SRM, Ariba) enable
enterprises to have access to market-aligned practices, while maintaining good collaboration with
suppliers.
For backend high-volume invoice processing, OCR (Optical Character Recognition) solutions, such
as WMD xFlow and OpenText VIM, can be deployed for automated scanning (into ERP) – this free
up the effort for human processing and errors. For high-volume payments and collections, bank
integration can be setup using EDI/XML/CSV formats. Online self-service tools (such as Concur
Claim, SuccessFactors, Taleo, Workday) can be deployed, to ease the administrative load.
For advanced planning and scheduling of production, SAP SCM or other best-of-breed alternatives
(such as i2 and Manugistics) can be deployed for an end-to-end supply chain solution. Specialized
engineering software (such as CIDEON PDM Drawings, Maximo Asset Management) can be used
to further enhance the product design and engineering architecture. External project management
tools that are more compatible to the MES chosen (such as Primavera) can be brought into ERP or
PPM for holistic analysis.
The demand for Enterprise Performance Management, exist even without an ERP in place,
matured applications such as SAP BPC, Hyperion Planning, Cognos TM1 can be used
integratively or without. Business Intelligence tools such as SAP BusinessObjects, Tableau,
Qlikview, PowerBI, can used to facilitate visualization and trends identification.
In a Banking organization, there can be Commercial Banking and Retail Banking scenarios.
Financial institutes deal with financial instruments (such as trade finance, debt, securities) as
products, rather than physical goods. The central module used would be FI, and CO; while a
myriad of trading applications becomes its sub-ledgers and sub-modules. The specific challenge of
this industry is stringent regulatory requirements for financial assets, hence it is recommended to
take up Financial Asset Sub-ledger (FAM) to meet the data granularity requirements of IFRS 9.
For commercial banking, there can be a variety of trading (or loans) systems used. Hence, the
Enterprise Architecture needs to include a layer of data harmonizing process before entering the
SAP ledgers. FAM is highly ECC compatible and has functions that support the liquidity coverage
requirements. In the event that FAM does not fit the Enterprise Architecture schema, a custom
application can be used to meet the intricate needs of Risk Weighted Asset Model. For retail
banking, it is recommended using Industry Solution for Banking (IS-B) for a smooth integration.
It is known that Deutsche Bank, for example, has been using ECC for years to consolidate its high
volume of financial transactions.
(1) Reports: This is for custom reports to meet the individual enterprise reporting needs. Each
enterprise belongs to a different industry and business environment, its needs for reporting differs.
ERP typically provide various reporting utilities for customized reports. For SAP, there is the Report
Painter tool for fast report generation in finance; whilst various Logistic Information InfoStructures
are available for logistic reporting – in both case there is no need to resort to programming. SAP
Infoset Query builder can be used to join data from both finance and logistics via its click-and-drag
interface; programming codes may be inserted to various spots for enhanced querying. Extended
reporting can be performed using SAP BW/BI. S/4 HANA provides HANA modeling capabilities for
extract analytical data in-place.
(2) Interfaces: This is for interfacing connectivity to meet the individual enterprise application
landscape. Each enterprise has different applications infrastructure, its needs for integration differs.
ERP will not know beforehand what these exact requirements are but may offer adaptors for
smooth interfacing. In logistics, it is possible to have integration with external vendor or even
internal vendor for order automation. In finance, it is common to have bank interfaces for automatic
bank transfers. SAP provides various pre-built interfacing mechanisms for logistics and finance.
Interfacing technologies include CSV, XML, EDI, SAP-ALE, SAP-IDoc, Web Services, etc. At the
frontend level, it is also possible to use external user interfaces coded in C++, Java, Excel or even
Python.
(3) Conversions: This is for bringing in legacy data into the ERP. SAP uses the Legacy System
Migration Workbench (LSMW) tool to load legacy data to standard objects. Data can be prepared
in an Excel file, and the LSMW will run through each record while data-posting into specific
transaction screens. Custom LSMW can be built.
(4) Enhancements: This is for adjusting standardized ERP processes. Each enterprise will have
its idiosyncrasies in its business processes, certain level of alteration is required. SAP provides
various enhancement techniques (such as Exits, BADI, BTE, Spots, etc.) for business alignment.
For example, the ‘Selling Type’ information needs to be captured in the Sales Order. Hence, there
is a need to create the ‘Selling Type’ input field in the Sales Order screen using Screen Exits.
During saving of the Sales Order, the ‘Selling Type’ is updated to the database - using Program
Exits.
The fundamental change of S4EM is to have a centralized ledger structure, aka the Universal
Journal (UJ). In ECC, a posting in FI, may lead to a posting in CO. Hence, at least two documents
are being created in two places. With UJ, postings are only passed once into one place. This
ensures high degree of data synchronism.
This disclaimer informs readers that the views, thoughts, and opinions expressed in the text belong
solely to the author, and not necessarily to the author's employer, organization, committee or other
group or individual. The author is not affiliated, associated, authorized, endorsed by, or in any way
officially connected with SAP®, Oracle® and Microsoft®, or any of their subsidiaries or their
affiliates.