Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Leap in faith - EPM cloud is here to stay ! | Main | B2B CPQ eCommerce Solution for Professional Service Sector »

Oracle R12 Shop Floor Footprint - Implementation Point of View


Oracle shop floor footprint can be defined as a collection of products/modules, interfaces, hardware, middleware, user interface; and their integration touch points required to support day-to-day production and inventory activities. At a high level, the ways of executing manufacturing processes and transactions in any ERP, including Oracle, are pretty similar - routing, bill of material, backflush, phantoms, work orders, etc. But we should acknowledge the fact that when it comes to designing a framework to get us to the point of recording production in Oracle, it is definitely 'not a one-size-fits-all' proposition.

In this article, I will try to provide a detailed overview of various offerings available to build a robust and efficient Oracle shop floor footprint. My intent here is to present some vital and practical pieces of information, which is generally not available in user guides or implementation manuals, to help make wise decisions while chalking out an optimal system design for an Oracle manufacturing implementation or upgrade. This blog post will provide important points/checklist for comparing solution options made available by Oracle in a few key areas in manufacturing.

The analysis shared in this post has been validated through client engagements and also leveraged in discoveries, proposals and proof of concepts. It can serve as a ready reckoner in drawing the shop floor blueprint for any client in manufacturing space using standard Oracle modules. In this post, I will cover 3 major topics that form the core of a typical Oracle R12 shop floor solution:

  • Manufacturing Execution System - for work order processing/production reporting
  • Shop Floor Process Automation - through integration using RFIDs
  • Mobile Supply Chain Applications - to facilitate point of use transactions using mobile devices


Representation of an Extended Oracle R12 Shop Floor Landscape

Manufacturing Execution System: 

Oracle Manufacturing Execution System (MES) was introduced in Release 12 (not available in 11i).  It is a revamped version of the traditional and most commonly used discrete manufacturing module - Oracle Work in Process (WIP). I have tried to list down practical advantages of some of the features offered by MES, that are not available in WIP:

  • Ability to transact multiple work orders at the same time: This comes in very handy when products are manufactured in batches with each batch comprising of multiple jobs. Operators can complete physically working on the entire batch and then process all related work orders in one go in the system, thereby saving time to access and transact each work order individually
  • Clock in, Clock out features to record actual labor effort: Users have the ability to report actual time spent directly through their MES workstation. This data can then be used to compare against routing labor to calculate variances. This can be further extended to record total time logged by an operator on any given day through Shift in, Shift out feature
  • Integrated Job Traveler and Labels: Traditionally, travelers and labels required to support manufacturing are printed separately. Subsequently, associating these documents with the actual job becomes a manual task. MES automates and streamlines the process by providing a capability of printing these documents directly through the workstation. The layout of these documents is completely configurable through XML publisher
  • Separate dashboards for operators and supervisors: Depending upon the department which they are assigned to or are responsible for, dashboards can be configured in MES to provide a single screen, user-friendly view. This can be personalized depending on the level of access/ownership/sequencing of work
  • External device integration capabilities for equipment data capture: To allow automated data collection from shop floor, MES allows device data to be directly collected into quality collection plans, either during manufacturing transactions or in a standalone mode. Such device integration is enabled through MES connectors provided by Oracle certified partners (for example, KEPServerEx connector from Kepware Technologies)

If you trying to include MES in your project scope, then here are some key implementation considerations:

  • Manufacturing Execution System is available for both, Discrete and Process Manufacturing
  • You can have both, WIP and MES installed on the same EBS instance and choose to use either one or both based on specific shop floor reporting requirements of departments/users within each site
  • MES user interface is largely HTML/OAF page based. Therefore, it is not easily rendered on a mobile device unless you deploy Oracle Smartphone Apps. Therefore, it is advisable to have shop floor computers or industry grade tablets for ease of access
  • MES license is sold separately by Oracle. It is not a part of the regular manufacturing bundle that includes WIP, and vice-versa. Contact your respective Oracle Alliances Manager for pricing details and discounts available for clients
  • It is a mandatory requirement to license MES module if you are planning to implement E-Kanban (one of Oracle's newer offerings in value chain execution track made available only in release 12.2 onward). However, please note that this is just a licensing requirement. It is not necessary to configure/implement Oracle MES to be able to use E-Kanban
  • For new sites going live on Oracle E-Business Suite, MES need not be implemented for use right from day one. It is a peripheral module, like Quality or Mobile Supply Chain Applications (MSCA), and can always be added to the existing Oracle landscape at a later stage

Distributed and Co-existent Models of MES:

In a distributed model, Oracle MES resides on a dedicated server while rest of the processes on a separate primary server. 'Near real time' integration between these two layers is achieved by means of ODIs (Oracle Data Connectors). This facilitates manufacturing reporting to continue even when the primary instance is down for planned or unplanned reasons. When the instance is up again, connection to MES server is re-established and data/transactions are automatically synced by ODIs. 

A co-existent model is used when businesses want to continue using their homegrown MES systems for recording industry specific variables/processes, but at the same time leverage the features offered by other EBS modules through integration. This model is typically deployed in scenarios where replicating such third-party MES system electro-mechanical interfaces in Oracle would call for complex customizations, heavy investment in new hardware/middleware and added maintenance.

Oracle Shop Floor Integration and Automation with RFID:

With a lot of new technology at our disposal, shop floor processes are getting more and more automated by the day. Although there is a plethora of options available, couple of solutions have always stayed on top of the list - Bar codes and RFID (Radio Frequency Identification). Let us understand the major differences between these two.


Bar Code



1D or 2D/QR (Quick Response)

3 dimensional

Physical Attributes

Printed Barcode

Physical Tag



Passive and Active (self-powered)

Volume of Information Held

Limited (1D: Low, QR: Medium)


Data Transmission

Not supported

Passive - No, Active - Yes

Data Receiver

Barcode Scanner (Static and Mobile)

RFID Reader (Static and Mobile)

Range Factor

Range of Scan Gun laser beam

Range of Near Field Communication (NFC) Device

Type of Scan

1 or 2 dimensional (Dot/Line/Block)

3 dimensional

Scan Angle Dependent






Cost Factor

Printing and stationery (label) cost

Cost of tags (reusable or one-time use)

Integration with Oracle

Indirect (through custom interfaces)

Direct (through standard middleware)

Mobile Supply Chain Applications interface

Front-end (through barcode scans while performing transactions)

Back-end (through middleware and APIs after RFID tags are read)

IoT Ready


Yes (through Oracle Sensor Server)

Smart Phone Compatible

Yes (through optical reader)

Yes (through NFC)

 In this article, we will be focusing only on RFID, for two reasons - Newer technology and more automation capabilities. A few key design considerations that one should take into account while pursuing RFID integration as a part of Oracle shop floor footprint are outlined below:

  • RFID integration with Oracle manufacturing and logistics modules such as Work in Process (WIP), Inventory (INV), Shipping (WSH), Warehouse Management System (WMS), etc. can be enabled through third-party middleware provided by Oracle certified vendors like Zebra or Intermec (a Honeywell company now). Having such middleware is a mandatory requirement since direct sensor based integration between Oracle EBS and RFID is no longer supported (this is confirmed by Oracle automation team)
  • Certain 'smart' printers are available in the market that can be configured in a way that labels with embedded RFID tags are printed upon work order completion transactions. Such integration is out of the box (through certified middleware), but requires special hardware such as 'smart' printers which are quite different than the regular label printers found on shop floor
  • There are APIs in WMS which can be invoked to perform Oracle transactions based on RFID scans. In these scenarios, in addition to deploying the standard middleware, some programming is also required in the interface code to avoid duplicate scans/transactions. This is true especially in an area with multiple RFID readers and tags, which is common in large facilities. The transactions supported, but not limited to, are:

    • sales order picking/shipping
    • inter-org inventory transfer
    • inter-org shipment
    • purchase order receipt/internal order receipt
    • in-transit shipment receipt
  • The above-mentioned transactions are possible with RFID integration even without WMS, through modules such as Inventory and Shipping, but it calls for a more complex middleware

Mobile Supply Chain Applications:

Note that Mobile Supply Chain Applications (MSCA) is different than Oracle Mobile Apps or Smartphone Apps. MSCA is pretty much device agnostic and can be deployed on a variety of supported hardware ranging from industry grade handheld devices to smartphones and tablets. This is not true in case of mobile apps which require an iOS or Android platform. There are 14 Oracle Mobile Apps for E-Business Suite that are currently available in a larger spectrum (such as HR, PO, MFG, PIM, etc.) while MSCA is restricted to manufacturing and logistics areas. I will be focusing only on MSCA in this post.

A lot of times, Oracle Mobile Supply Chain Applications (MSCA) and Warehouse Management System (WMS) is perceived to be one and the same. However, that is not correct. Although there are a lot of similarities between these two and the user interface is almost identical, the nature and purpose of each is widely different. To begin with, WMS is a product by itself while MSCA is an option that is available under a product or bundle in the Oracle applications price list. For example, MSCA can be optionally bought as an option with Discrete Manufacturing product bundle.

Consultants and customers are often faced with a difficult question "Should we implement MSCA or WMS?" Addressing this accurately in the early (scoping) stage of the project itself is critical because a WMS implementation is kind of set in stone. Once WMS is implemented, reverting it is a lengthy and complex process, and vice-versa. This is not the case with MSCA though because, as also quoted in the MES section of this post, MSCA is a peripheral module and can be added or disabled later. Let's compare MSCA v/s WMS on a few factors that can hopefully make the choice between the two somewhat easier.




In-built Processing Logic


MSCA just provides a user interface to perform Oracle transactions from a mobile device. It does not contain any processing logic to drive transactions


WMS has a rules engine that allows users to define rules and conditions to drive and manage inventory movement and shop floor transactions

Guided Material Handling


MSCA is just a different way of perform transactions in lieu of regular Oracle screens. It does have the ability to provide picking and put away recommendations to operators


WMS can provide real time picking/put away recommendations based on inventory situation and honor handling requirements as set up in rules associated with tasks

Startup Time/Effort


Once MSCA is licensed, its just a matter of defining menus and responsibilities based on level of access to be granted, to get it up and running


WMS requires an elaborate module setup to develop rules, testing and fine-tuning of the rules to deliver an efficient and effective system


Almost Negligible

Once MSCA responsibilities are defined, there is hardly any maintenance required unless there are enhancement requests to modify access or personalize screens

Some Effort Required

WMS rules set up during initial implementation need some upkeep and monitoring to make sure tasks and recommendations are satisfying business needs in the long run

Target Facilities

MSCA is more suited for facilities with simpler layouts where the need is to allow transactions to happen from mobile devices while operators can decide upon material storage and picking locations visually without needing system recommendations

WMS is suited more for large and complex facilities that want to have rule based material movement, skill based task management, etc. where the size of the warehouse makes visual storage and picking/put away choices prohibitive for the operators

Best practices for implementing either MSCA or WMS are more or less the same. In addition to configuring the module itself in Oracle, it also needs some preparatory work on business side to get ready to adopt the 'mobile way' of doing day-to-day transactions.

  • Locators: Bar code your physical locators. It is recommended to barcode both, subinventory and locator together in single barcode since in almost all mobile screens these two are next to each other
  • Quantity: Avoid barcoding quantity on any report. This will ensure that operators key in the actual quantity used instead of one printed on the report, since both could be different
  • Standardization: Collaborate with external parties such as suppliers, logistics providers, etc., who are a part of your extended supply chain, for barcode compatibility and standardization
  • Mobile GUI: There are 2 options available (Java and Telnet). Determine which one works best based on user base, volume of transactions and other attributes impacting the design
  • Personalization: A lot of extra fields are available on mobile screens. Do the necessary due diligence to hide/default these through personalization to render a more user-friendly interface


This blog post is largely based on my consulting experience working with various clients in manufacturing space, with nature of production ranging from simple assembly operations to high volume end-to-end manufacturing to engineer-to-order scenarios. Additionally, feedback from Oracle product teams, lessons learnt and details not already documented in standard artifacts but uncovered while investigating these topics have been incorporated. Therefore, I hope that the information shared will prove to be useful for consultants, business analysts and customers while dealing with similar situations, especially when a practical experience driven insight is desired. Please feel free to post questions either here or reach out to me at and I will be happy to answer.

"You must not expect the customer to understand the benefits of your technologies. That's your job!" - Akio Morita (Co-Founder, Sony Corporation and Business Leader/Visionary) 


Excellent write up Manish

Good informative article Manish.

We are exploring some methodology to track materials online from manufacturing and inventory (warehouse) and one of the options is RFID. The other of course is barcode. Though this is not for Oracle.

This is a wonderful article, Given so much information in it, These type of articles keeps the user's interest in the website, and keep on sharing more ... good luck.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles