Intro:
In the last blog, we lay down the business requirements per the inputs privided by the Shop floor executives. In this blog, let us explore the systemic issues that would be required of an application that would render business value to Org.A. ALet us assume that Org.A is in the process of assembling laptops.
Designing the process work:
The SFC application should be in a position to control both Retail and MTO orders using similar tools and features. Though the process would vary slightly for each order, in general they would require the same type of operations. The same logic applies to the roles that would be involved in processing these orders. At the start of manufacturing operations, machine operators (Role 1) would print out a travel card (MTO) or WIP label (Retail) for each unit ordered and attache it to the unit. The travel card/WIP Label would then need to be printed with a bar code of the input number. During various stages of manufacturing, operators would need to scan bar codes, using hand-held infrared devices that would go into the finished unit. This process would also allow for quick and accurate data entry for tracking components such as hard drives and LCDs, so that all the serial numbers for every component are directly linked to the serial numbers of the computers produced. Furthermore, the travel card for each finished unit is directly linked to a specific customer order. For the MTO orders, this process would need to allow each finished unit to be built for a specific customer order, from start to finish. For Retail orders, the process would need to ensure accurate manufacturing. Printing of Travel cards for MTO and WIP labels for Retail would also need to consider reprinting and reassigning them to different WIP orders. A seperate GP driven approach would have to be considered to handle returns in terms of "Repair and return", "Product recall" and each would more or less be handled in the backedn R/3 system with custome Goods movement types.
While assigning/re-assigning travel cards, the operator would need the information about the finished Unit, the service tag number, the consiguration status on the assembly line, and the finished good number. Presuming that the existing SFS is a java application that processes this logic, this provides is us with the input of how to handle or design the composite xSFS.
Since Org.A would also receive MTO orders without any notice, xSFS would need to age the MTO orders for two days before it allows operators to begin work on them. The ageing report would need to be sent to R/3 and he reporting out of BI 3.5 that needs to be flashed on a proactive basis on the Shop floor manager's dashboard. This two-day aging period would allow production to plan when to produce the orders, and would also give the customer time to cancel the order without affecting production. If a customer does cancel an order during aging, xSFS would need to reassign the service tag for the old order to a new one, running the reassignment process as a part of aging. And with each new order, xSFS must check to see if a customer has canceled an order for the same laptop configuration so that a matching configuration for a new order can be reassigned. This way, xSFS must eliminate the redundancy of changing production plans or disassembling units unnecessarily.
The Integration needs to update R/3:
xSFS would need to send up to three WIP transactions to R/3:
1. During the Input Process, it must send a WIP Move after the operators add all of the correct components to the unit
2. During the Output Process, it must send another WIP Move when the unit is completely assembled and inspected.
If the unit needs to be repaired, and must await the arrival of a part, xSFS must send details to R/3 to create a repair job for the unit, reverse the first WIP Move for the unit, and reduce the quantity of the original job to indicate goods movement.
Designing xSFS with CAF 7.0:
Since there is already an existing Java application that takes care of the processing logic, Org.A has the option of porting this application onto the SAP NetWeaver server. Since this application comes in with a lot of political baggage as well, removal of this system may not be possible if it can be "NetWeaver enabled" (as the users refer to it). Taking this application, porting it onto the SAP NetWeaver server, taking the exposed APIs and creating wrapper beans on top of the same to be called through webdynpro DCs made as callable objects created into actions, assembled into blocks, create the processes in the GP design time and run through the GP Runtime attached to a specific roles designed in EP (pulled in from R/3) of an operator, shopfloor supervisor or the shopfloor manager or administrator. Using CAF becomes a very useful and a mandatory aspect for designing the composite.
Now, the question comes in, how do we define this xAPP as - a light-weight composite? A medium-weight composite? Or a heavy-weight composite? Or any other classification that you may wish to have. Since the processes would more or less be defined between a PBNW application and the core R/3 backend and BI. And the scalability factor of upping this to incorporate Analytics in the future and the architecture of embedding the MES system as part of the entire Product development cycle integrated with multiple systems falls in place once planned right. Every activity needs to be Role driven.
Primarily using the IDOC and the JDBC adapter, the integration work is not much that would initially be carved out. Since the volume of data transfer may become large, or files with design drawings and kitting details tend to increase the message size, the use of XI has been warranted over the use ESA. Another reason for bringing XI in the loop right now is to move more and more applications to the useage of the same post upgrade and driving more work with the useage of ABAP proxies and doing away with the existing SeeBeyond EAI application.
The Goods movement would now need to be triggerred manually via BAPI imported as external services to be mapped to enitity services, called by application service and then converted into callable objects to be embedded within a Guided procedure step within a process while designing xSFS using CAF. To cancel orders or product recalling, xSFS must allow to to delete components from an assembled unit, and reassign them to the pool of components available for assembling new units and update the backend R/3 system. This WIP moves are to be initiated using XI in the long run once the process becomes stable and more sophisticated. Once this is done, a high-level project plan could look somewhat as below:
Conclusion:
What began as a "white-space" or an existing perceived gap within R/3 and by not introducing any other xAPP to avoid licence costs, Org.A is now poised to see how it can take on the complete Product Life Cycle Management with this approach. Starting from idea generation to design and engineering towards production or procurement till revenue recognition and top-management reporting on a proactive basis, Org.A is in the process of designing its entire supply chain with ARIS and integrating iPRO and xSFS into the fold of the process execution.
The Arrived Definition of a true composite:
When Org.A brings over the entire Supply chain execution from S&OP, MES, Demand Forecasting, PLM and Logistics into its custom built "next practices" as ONE single process chain, slowly bringing together the various existing, upgraded and reformed systems within the process umbrella to provide a role-based insight into the process chain, it provides a business reason for the useage of the Composite Application Framework and the roadmap with ESA.
