SAP Eyes the Shop Floor
For some time, SAP has been attempting to get closer to (i.e., to get into the hearts and minds of) plant-level personnel with its "adaptive manufacturing" and "adaptive business networks (ABN)" themes. The introduction of the SAP Plant Manager Dashboard in 2004 demonstrated that SAP is dead serious about extending its reach onto the plant and shop floor. With this product introduction, the vendor has delivered a solution that aims at integrating existing disparate plant execution systems to provide a unified view of the plant, and provides the likes of the plant manager (or even blue collar operators) with access to all pertinent data (e.g., near real time notifications of delays or any other glitches in manufacturing processes) on a single dashboard.
Leveraging SAP NetWeaver, the Plant Manager Dashboard (and other forthcoming role-based siblings that are in the works, such as Production Supervisor Dashboard, Maintenance Technician Dashboard, and Quality Inspector Dashboard) primarily aggregate and present information to users, empowering them to manage and improve manufacturing performance. At SAPPHIRE 2005 and many similar events, a slew of partner companies, such as OSIsoft, IndX, Siemens, NRX, Vendavo, Visiprise, WonderWare, and Yokogawa, have repeatedly demonstrated their ability to serve up plant level information to SAP's dashboards (although OSIsoft, Vendavo, and Visiprise have not yet integrated to the Plant Manager Dashboard).
With such extensive integration forming a part of their plan to enter the shop floor, SAP must necessarily be concerned with connectivity standards. In fact, SAP has for some time been addressing global, industry-wide concerns about the current lack of agreement in defined standards for connectivity and interoperability between various plant automation, manufacturing execution, and enterprise level systems. SAP has been particularly vocal about its support for Instrumentation, Systems and Automation (ISA)-95.
This is only part of a general upsurge of interest in standards-based interoperability, which indicates that manufacturers have a real need for better options in connecting business processes throughout the organization. For instance, though Oracle, SAP's major archrival, has not shown as much enthusiasm for ISA-95, it has been one of the leading supporters of Open Applications Group Inc. (OAGi) since its inception. Oracle has delivered broad support for Open Applications Group Interface Specification (OAGIS) scenarios and business object documents (BOD) within its Oracle E-Business Suite.
Given OAGi's rich library of manufacturing scenarios and messages defined to support the broader needs of discrete manufacturers, contract manufacturing, and new product introduction (NPI), Oracle's support for their standards may give it an advantage over SAP in discrete manufacturing industries. Moreover, ISA-95, which focuses on process industries and plant-level interoperability, lacks support for e-business collaboration. Many global manufacturers have thus been using OAGIS for their business-to-business (B2B) integration, with various automotive groups, such as the Automotive Industry Action Group (AIAG), assertively building multi-tier supplier collaboration scenarios. On the other hand, SAP claims to have recently organized a Discrete Manufacturing Interoperability Standards group that is tasked with looking at standards such as OAGi, ISA-95, and others. In addition, it has commenced a pilot project with a customer and partner currently using OAGi.
So, despite whatever advantages Oracle's support for OAGIS gives them, SAP remains in the blessed position of being the leading enterprise resource planning (ERP) or supply chain management (SCM) provider in the manufacturing sector. With this role comes a certain amount of responsibility. The vendor's philosophy is that it wants a long-term relationship with the customer. Thus, as it thought the interoperability idea through, it became clearer and clearer to its management that SAP could unleash something useful for the industry, without giving virtually anything up from its position. Specifically, the software leader might be able to do a lot of good things for its customers (due to a big pent-up demand for solving the interoperability problem) on the one hand, and, on the other hand, SAP should in turn benefit because it would then be able to demonstrate the power of SAP NetWeaver in this regard.
SAP may be able to capitalize on the interoperability trend in another way as well, as its SAP Manufacturing suite may help close some gaps in current product functionality. This is because investments made in systems managing production processes in plants and within entire supply chains are playing a larger role and are gaining in value, as companies move toward collaborative uses of data to support business processes (for a more detailed discussion, see The Importance of Plant-Level Systems) By integrating plant- and enterprise-level systems, one can close the loop with factory scheduling. This provides improved modeling of asset, equipment, labor, and other production-related side constraints, and reflects their actual status in near real time, so as to allow the timely escalation of threats to order delivery performance and overruns on manufacturing costs. In fact, the importance of using shared equipment and production data models to provide shared visibility of planned maintenance and its impact on production scheduling cannot be overstated. Nonetheless, the product design data available in product lifecycle management (PLM) systems is still disconnected from plant-level systems, which should know intimate details of the manufacturing process and track how products were actually made. This might be rapidly changing owing to the facts that the SAP Manufacturing suite now incorporates some PLM functionality as a part of SAP NetWeaver, and that NetWeaver is now connected to the shop floor with the SAP xApp Manufacturing Integration and Intelligence (SAP xMII) composite application.
However, SAP recognizes their inability to structurally improve manufacturing processes themselves because it is incredibly difficult to map what is happening on the shop floor in detail. It is even more difficult across multiple plants, as the vendor has to provide customers with the ability to not only to get the workflows right, but to assemble some of the data needed to do structural improvements.
Researching Manufacturing Needs
Manufacturing organizations are now placing a much higher value on the information detail (e.g., labor, inventory measures, lead times, maintenance, product data accuracy, etc.) generated, aggregated, and used by events and processes within real production and logistics worlds. This is valuable not only in manufacturing organizations, but also in many related environments where operating in near real time is critical. With this in mind, as SAP was planning the 2005 delivery of its manufacturing dashboard, it reportedly talked to over 80 plant managers and over 100 production supervisors, by asking them flatly "what do you do during the day to fulfill your role?" and "what do you need to be made more productive?".
The vendor reportedly found out that what the managers and supervisors needed was a collection of consolidated information from a variety of sources and applications and a detailed awareness of what is going on in the real world. A portal might provide the ability to bring information together technically, but the vendor recognized that there are many gaps that need to be filled for ultimate customer satisfaction. Moreover, one should not forget that there are other areas, such as shop floor applications, to tap to make the business more agile.
All of these requirements center on the idea of near real time information sharing and use. In fact, many newer business initiatives, including applications of collaborative manufacturing strategies, require near real time information availability to satisfy even simple needs. In practice, operating an adaptive enterprise requires real world awareness, which means providing timely information as well as establishing business processes that bridge traditional application gaps. This is the space where SAP sees plant-to-business (P2B) interoperability playing a key role, because all the physical sensors are already in place, so that users should simply have to leverage the potentially vital data.
Summary of Manufacturing Needs
The synchronization of inventories and production across a supply network requires knowledge of the current status of events, such as what is happening at this moment, what is expected, and so on. It is insufficient to have a report on what happened last week or even yesterday. To be truly "in sync" requires current knowledge from the plant or warehouse level processes themselves, and not a "best guess" as to what was scheduled or what should have happened.
SAP has seen that in most of its customers' environments, production systems on the shop floor are not synchronized and integrated with their enterprise-level counterparts. Thus, there is a lack of timely and accurate information, and business processes are disconnected. Consequently, production personnel in these environments have been spending a huge portion of their time hunting down critical information, severely compromising their productivity and performance.
Production managers typically get a view of what happened in the past week or, in the best-case scenario, the past shift. If there is an anomaly, the manager would need to get some more information in order to understand why this problem continues to occur. To get the associated data, the operators need to go through a large number of systems in order to pull together all the information they need. This takes a lot of time, since, for example, a more complete picture of a single batch at the detail level is spread across many different systems and it takes time to get that information back. Production supervisors and plant managers are therefore constantly fire fighting with exceptions because of a lack of automated exception-based management, which adds latency, delay, and cost, while production personnel cannot really measure, monitor, and control their key performance indicators (KPI).
In fact, what has been driving a lot of the manufacturing intelligence dashboards installations out there are enterprises that pay their operators in accordance with their performance. This means that such enterprises then have to give the operators a view of how they are doing. One of the largest chemical companies in the US, for example, is paying its operations people a large part of their remuneration based on their performancei.e., achieving first class quality and conformance to a specification.
What Has Oracle Been Doing?
While SAP and Microsoft (via SAP Enterprise Portal and Microsoft SharePoint Portal Framework, respectively) have largely focused their forays in manufacturing on partnerships and on delivering performance visibility via composite applications featuring manufacturing intelligence dashboards (e.g., for roles such as the plant manager, maintenance manager, quality manager, and production supervisor) that provide business context to manufacturing data residing in a fragmented set of applications (see Plant Intelligence As Glue For Dispersed Data? ), Oracle is taking somewhat a different approach. In particular, as first reported in AMR Research's August report entitled Integrating EMI With ERP: A Tale of Two Vendor Strategies and confirmed by our discussions with Oracle, the vendor has been adding onto its deep native manufacturing operations management capabilities, which are tightly integrated with core ERP functions such as financial accounting and resource planning.
Following its traditional unified data model mantra, Oracle knows that sharing common equipment, manufacturing process, product definition, planning or scheduling data models, etc. can often obviate the need to build composite applications that map and bridge the gaps between data models in different application domains. Integration with Oracle E-Business Suite 11i (which also features portal and dashboard analytics capabilities) should in fact close the loop between real time manufacturing operations and scheduling, allowing for immediate visibility and escalation of issues, such as non-conformances, capacity constraints, and other real time manufacturing events that might often result in, for example, decreased productivity, increased scrap or rework, and extended lead times. If all this can be done on a single instance of Oracle E-Business Suite, one should not have to worry about customary best-of-breed concerns related to rationalizing data models and importing data from other applications.
As for the shop floor execution, natively provided workbenches in the Oracle Work In Process and Oracle Shop Floor Manager (OSFM) modules are designed to let users create and simplify the routing operations and automatic data collection (ADC) process from the shop floor, while still providing visibility into production operations at a global level. Some other features include the centralized creation of routings and workflows that still accommodate local customization, part- and lot-level traceability for root-cause analyses, product genealogy data for aftermarket services, in-process quality tracking, work-in-progress (WIP) tracking, and mapping of "as-built" records with the "as-planned" product designs. These capabilities often come in handy for customers in the medical device and high-technology or electronics markets.
In addition, on the higher-level planning and coordination side, some users have already been using Oracle Discoverer and Daily Business Intelligence (DBI) to monitor manufacturing performance against goals in near real time. This is done by seamlessly integrating performance metrics with transactional data and incrementally updating the metrics as transactions occur. Furthermore, Oracle Enterprise Asset Management (EAM) helps customers tackle asset performance. The additional capabilities for deeper cycle time analysis expected in future releases should help provide customers with an increasingly holistic perspective on manufacturing performance and the factors that influence it.
This wealth of native capability does not to imply that Oracle is not open to partnering for direct, plant-level, or machine-level integration in environments where the complexity and transactional volumes exceed its ability to deliver standard application functionality. In fact, Oracle provides a comprehensive library of application programming interfaces (API) for integrating with third-party plant-level applications when this is required or preferred. For instance, Mestec, a UK-based provider of manufacturing execution systems (MES) and electronic production management systems, has reportedly been recently asked by Oracle to integrate its plant-floor data management solution with Oracle E-Business Suite. One would also be able to find a number of Oracle customers that have already invested in an MES application from vendors such as Camstar or Visiprise.
Nonetheless, in addition to bolstering the market awareness of its plant-level capabilities, Oracle will have to more clearly articulate and educate customers on its partner strategy and standards approach for integrating to plant-level systems. In particular, Oracle must make customers aware of when they should look for a best-of-breed approach versus a "one-stop-shop" approach provided by Oracle, with its associated lower total cost of ownership (TCO). This market awareness should come bundled with a strong manufacturing consulting and system integrator (SI) partner network.