Overview
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.
|
Attribute/Feature |
Bar
Code |
RFID
Tag |
|
Dimensions |
1D or 2D/QR (Quick Response) |
3 dimensional |
|
Physical Attributes |
Printed
Barcode |
Physical
Tag |
|
Nature |
Passive |
Passive and Active (self-powered) |
|
Volume of Information Held |
Limited
(1D: Low, QR: Medium) |
Significant |
|
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 |
Yes |
No |
|
Re-programmable |
No |
Yes |
|
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 |
No |
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.
|
Factor |
MSCA |
WMS |
|
In-built Processing Logic |
No MSCA just provides a user interface to perform Oracle transactions from a mobile device. It does not contain any processing logic to drive transactions |
Yes 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 |
No 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 |
Yes 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 |
Low 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 |
High WMS requires an elaborate module
setup to develop rules, testing and fine-tuning of the rules to deliver an
efficient and effective system |
|
Maintenance |
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
Conclusion:
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 Manish_Naik@infosys.com 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)