The Architect's World - Episode 40

[Former Member]

Intro:

The ISV and the SI community seems to be quite abuzz with creating "Composite Applications", without the market truly defining what formulates a composite application, what makes an application to be called a composite, how Org.A could do away with the new paradigm of development with what the market now calls the world of composites. In the quest to define a "Composite Application" or how to segregate "Light-weight composites" from "Heavy-weight composites", this blog stems from a discussion with a range of bright and experienced folks I met in Paris during Sapphire to formulate the Enterprise Services Community discussions. Continuing with our quest of building composites, and segregating the same into various brackets, let us now formulate a business need with our fabled fictitious organization - Org.A, that considers a Shop floor execution as an area defined as a "white-space" (published ones as "white-spaces" and non-published ones as "blind spaces").

Forget the technology or the platform - Formulate the Business need first :

What we will now do is to consider the requirements that will help us conceptualize the business processes to be enabled with the help of an application that will leverage the existing SAP landscape, will call for custom development and deployment on an SAP NetWeaver platform, take in and push data to multiple applications, use role-based approached to accessing business content to carry out the transactions and finally, reporting using BI driving up to Analytics. Once we formulate the need of this application, we will try to see how this can help us as follows:

1. Help us in creating pigeon-holes for composites to be slotted into

2. Create and define parameters to identify and slot composites into

3. Define the components that will be necessary to define what a "composite" should potentially have

4. When an application should be called a "Composite"

Following are the steps that one must, as an ESA Architect, do before creating our new composite Application. Let us call it x-SFS

Step 1: Identification of the white space per Org.A's SAP landscape - Done, it is X-SFS

Step 2: Lay down the business process requirements and come out with what the business application should do

Step 3: Identify the roles/the players who will use this application and the processes that they must follow

Step 4: Lay down the systemic requirements in context of the business requirements and conceptualize the system

Step 5: Consider the technological/business platform to enable the most efficient way forward

Step 6: Build it

And finally, use this example to derive our set of definitions around "Composite Applications".

Business Consideration 1: Definitions - Shop Floor System Overview:

Defining Web MTO - With Web MTO (B2B) orders, an Org.A customer places an order for a configurable material via an external facing portal (It is incidental that this could be an ideal candidate for the SAP NetWeaver portal as EFP) on a local database, fragmented with the Internal SLD. The plant downloads the order directly using an existing non-SAP middleware and reports for orders of all products can be printed and sorted freely, to allow for production planning and scheduling. POS orders (orders made at Point of sale at retail stores) and B2B (Business to Business orders for custom configurations) are special types of MTO orders. Retail orders will be defined in Org.A as more traditional orders of it's products and model lines. For example, Org.A supplies retail stores with set products and model lines, each one with exactly the same components. And Exchange orders and Global Org.A Direct orders (Global Org.A Direct orders—orders handled directly by another Internal division focused on International sales) are special types of retail orders.

xSFS should be needed to control both Retail and MTO orders using similar tools and features built on the same platform built on an SAP landscape primarily. Investing in development of one should only be reusable in the other with minor tweaks. Though the process varies slightly for each order, in general they would require the same type of operations. At the start of manufacturing operations, operators print out a travel card (MTO) or WIP label (Retail) for each unit ordered and attach it to the unit. The travel card/WIP Label is printed with a bar code of the input number. During various stages of manufacturing. Operators need to scan bar codes, using hand-held infrared devices. This process allows for quick and accurate data entry for tracking components as part of their products, so that all the serial numbers for every component are directly linked to the serial numbers of the materials produced. Furthermore, the travel card for each finished unit is directly linked to a specific customer order. For 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 manufacture. Though the processes would differ between the two lines of business within Org.A, one simple truth emerges - the usage of reusable components within the applications for different lines of business, the similarity in the roles that the individual entities would perform, the similarity in the dashboards needed, the reporting requirements and the overall common set of procedures as standard operating procedures within xSFS.

xSFS would need to ensure accurate manufacturing information about the MTO and Retail finished goods. It is to be used during the production process to capture and track information about the base units that are shipped in from a different geo and stored in Org.A's North American plant, adding parts to them, producing the labels for the finished goods identification, and needs to ensure that operators don't add incorrect parts to units. This application also needs to work with other Org.A applications, SAP and non-SAP, and processes to ensure accurate accounts, update product and order information, and be in position to produce reports that can be triggered on a periodic basis, on event of exceptions and have the ability to be tinkered around within an excel sheet. This application needs to be at the center of many other applications that control production, inventory accounting, and fulfilling sales orders as a mesh of applications within Org.A's landscape. xSFS needs to work in sync with the PP module to follow and record the completion of units. xSFS is in the middle of the process as a "white-space" ,with transactions occurring in R/3 both before and after. First, Retail and MTO orders would flow through the Materials Requirements Planning (MRP) process. The MRP process would need to create the demand to evaluate how many new units would need to be produced to fulfill the demand. The demand would then need to get stored in custom Z-tables and would need to feed xSFS periodically. (A point that comes to mind here is - To build and certify an xApp, do you need to certify the custom objects first?) At the same time, the new BOM information also needs to flow into xSFS (via a middleware which would later on need to give way to XI) so that the MATO configurations within xSFS are current and accurate and the production would need to take place (Handle from SAP to xSFS and then back to SAP). As production would occur, two WIP moves would need to move from xSFS through a Z-table in R/3. That would mark the production stages for a unit. The first WIP move would need to marks the completion of the first stage of production. At that point, R/3 would need to “backflush”, or record the depletion of the Raw Materials Inventory used to create the unit. Once the unit is complete, a second WIP Move would need to be sent to the Z-table to mark the completion of the item. As with the first move that depletes the Raw Materials used from inventory, the second WIP move would need to move the unit to Finished Good Inventory.

Business Consideration 2: Production process Overview:

The Org.A production process contains several processes within it. First, various information sources would need to update xSFS with order, BOM, and other information on a periodic basis. Then, using this order information, the Input Process would need to begin building a unit to fill a customer order. The output process would then need to take the unit and complete it, while checking to make sure that the finished goods were built correctly during the entire process. Additionally, two processes, Repair and QA, would need to take place for some units. For example, if a unit is to get damaged during the Input process, it has to go to the repair Process. Or, if QA would randomly select the same before it is to be shipped, it has to go through the QA process, where QA would need to audit its production information. The Ageing or the final inspection process for xSFS would be considered in the Phase II of the build . xSFS's database would need to get updated with new information such as a new Bill of Material and orders from R/3 would need to flow into the system using the existing EAI application. At the same time, the xSFS processes would need to run, and control the time it would take to release orders and ensure the reassignment of cancelled orders. These orders would be aged in xSFS for a couple of days before being released for production as the beginning of the input process to avoid further changes if they have to come in (An area that needs looking into).

Once xSFS would release an order for production; the Input Process would need to begin. A Line Operator would print a travel card (MTO) or a WIP label (Retail) to keep track of the unit during production. After activating the unit, they would use xSFS serial capture (scanning) to add components to it, scanning each component to the travel card or WIP label depending on whether its an MTO or a retail product. While the Operator would scan components, xSFS would need to start a “Tac Time” timer to track the total time the Input Process would take. It would also need to validate each component as it would be scanned to ensure that the operator doesn't add any incorrect parts to the unit. At the Input Configuration, the Operator would have to inspect the unit and then scan the unit. xSFS would need to validate that all the required parts have been added correctly during the Input Process to ensure that the unit is complete and correct when it leaves Input. Then, xSFS would have to send a WIP move to R/3 to record the Input Process completion.

Business Consideration 3: Input process Overview:

During the Input process, if an operator were to discover that a unit needs repair, they would have to establish the process to sent the unit to Repair before it gets to Aging. As the unit would be physically moves, the Operator would need to scan and record it to track the location of the unit while in repair - the same has to show up in a report that would need to list all items in repair or QA. Once the unit is to physically arrive in Repair, a Repair operator would need to evaluate the problem to see whether they can repair the unit with available parts. The same needs to be captured and probably so - online on xSFS. If it can be repaired, then the unit would have to be repaired and would need to be scanned and returned to Production. This set of Guided procedure would be known as "Repair and return" process. The unit would then have to complete Aging and move to the Output process, all the while xSFS has to be tracking the unit. If the unit were to arrive in Repair and would need a part that is not in stock, then the Repair personnel would need to scan the unit again to move it to an area that is “Awaiting Parts”. During this scan, xSFS has to initiate a WIP move to reconcile the WIP transactions for both the unit and the job the unit would belong to. This way, R/3 would have accurate record of both where the unit is, and where the rest of the job it originally belonged to is. The same would be sent to BI. Once the part would arrive back, it needs to be re-scanned back to Repair, and xSFS would need to record another WIP Move for the unit. The Repair operator would then repair the unit, and send the unit to Aging, then to Output. A set of procedures for each process flow that can be streamlined to ensure process compliance.

Business Consideration 4: Output process Overview:

During the output process, the unit would go through several stages of checking with each stage confirming that it successfully completed the previous stage. First, once the unit has to complete Aging, it has to begin the Final Inspection. At the end of Final Inspection, the process would have to flag the completion of the process with a move to finished goods inventory and label printing. Once the process is complete, the operator would need to scan the unit to print a label (Retail) or Shipping Label (MTO). Finally, the operator would need to prepare the unit for shipment. A few randomly selected units would go to Quality Control. This is a standard process that would need to be intuitive with no skipping of any processes steps.

Business Consideration 5: Quality process Overview :

If a unit is to be selected for QC before it’s shipped, Operators would have move it to QC in xSFS as well, and retrieve production information from xSFS, finally audit the information to ensure that the unit completed production completely and accurately with this information being recorded in xSFS.

Next Steps:

With the above as an application to be built, we will now analyze in the next blog as to what would make this a composite application, why should it qualify to be called a composite, why the criteria to define composites become so important and finally, what could be the different types of composites.