Having completed the M&A spree over the past 4 years, Org,A now has a task at hand in bringing sanity across the board with the SAP NetWeaver platform. Primarily being a core manufacturing company, Org.A’s supply chain activities today are not something one would term as “world class”. The approach that has been taken by Org.A in the past has been – do away with whatever legacy applications one can and have it replaced by core SAP R/3. If the functionality is not met, then customize. If customization effort is too high, go for a BOB application. EAM is an area that has remained the focal point for Org.A. It needs a custom solution for Asset Data Management owing to the very nature of its business that requires heavy capital expenditure on assets for manufacturing. Across the multi-plant enterprise structure of Org.A, there needs to be information available for transferring content and data from ancilliary engineering companies, original equipment manufacturers, and the Org.A plant community based on a role-based workspace front-ended by the enterprise portal for a similar look and feel for capturing key asset information across Org.A’s supply chain initiatives. This is an over-arching requirement that has Org.A segregate its key manufacturing functions like Sales and Operations planning (SOP) activities, Demand management (DM) activities, manufacturing execution (ME) activities, Supply Planning (SP) activities, Manufacturing and Procurement release, Procurement execution and enterprise asset management (EAM).
The end goal is to create a Composite Application(s) for the Manufacturing division to provide a business solution for the entire Demand-to-make process, that integrates seamlessly with SAP R/3 and SFE, extended to monitoring via black-berries using MI in the future (for QC moved goods), provides reports on exceptions in the supply chain using BI Alerting with BI3.5 that pulls in data from mySAPERP 2004 leading to executive dashboards with Analytics to provide a business solution integrating the shop floor and the rest of Org.A. The core mantra being supply chain streamlining, the ability to adapt to changes dynamically to consider demand, forecast and supply collaboration by building in principles of lean manufacturing is what is needed at Org.A today to enable real-time information between the SFE and business and to provide visibility into costs for material, labor, assets, plant and equipment maintenance and MRO supplies to increase product quality and decrease costs.
Process #3: The demand-to-fulfill process:
This, I call the “Build a uniform layer” approach.
Platform Approach #3: The GP approach to increase efficiency:
The solution that needs addresing demands an approach that can be achieved by providing a single UI across the organization to cove activities across its key manufacturing functions which include Sales and Operations planning (SOP) activities, Demand management (DM) activities, manufacturing execution (ME) activities, Supply Planning (SP) activities, Manufacturing and Procurement release, Procurement execution and enterprise asset management (EAM) – which, incidentally can run on core R/3 or 3rd part applications, or home-grown applications. Whatever be the backend today, a single UI is needed that is based on Guided procederes – may or may not be driven by ESA with a corporate branding across the board for the supply chain, which cannot be achieved by ITS-based standard business packages or custom web-dynpros. The solution is to be based on the existing IT infrastructure of Org.A and needs to enable the delivery of information securely over intranets, extranets, or the Internet without the need for modifications.
Potential ESA Candidates:
The solution that needs to be built has to keep in mind the fact the 57 instances of R/3 is more or less consolidated, and the environment of operations is ECC 5.0. Org.A is proud of the fact that it has bought practically everything off the SAP menu. So, now the focus is more strategic to provide a single, standards-compliant platform that provides a single UI that weaves together all the best practices in various functions across the value-chain as guided procedures and weaved through a single portal (Internal and external) for employees and business partners to have a single front-end to refuce complexity of operations and increased efficiency by doing away with uinnecessary screens of pre-filled junk. A near-real-time analytics engine is needed which should proviode for alerting, analytics, broadcasting and standard reporting to create a decision support system that builds on KPIs. The options available in fornt of Org.A are mainly three. The first, being the simplest and the most expensive – go for an xAPPs that does the job and fits in specific areas integrated with the current environment and UI guidelines and having the rest of the BOB applications go through the same route. The second option is to build everything onto the core ECC 5.0 platform and customize in ABAP to create the extended functionality needed and doing away with BOB and 3rd party and achieveing the single UI based on GP approach. The third idea is to have Org.A build its own applications as an extended form of its existing custom developed to be tweaked further and taking the custom web-dynpro route towards having them towards the single GP based UI vision.
Once the GPs have been identified based on the potential business process mapping in ARIS, integrated to ECC 5.0 via SolMan and XI for operation mapping and execution for ccBPM, the logical layers now help you, as a Solution Architect, identify the candidates that could be ideal for ESA. For example, Post the MRP run, the production process that contains several processes within it. First, various information sources update SFE with order, BOM, and other information on a regular basis Then, using the order information, the Input Process begins building a unit to fill a customer order. If this were to be conducted across multiple applications involving business partners, it would make sense.
The other example being the output process, which takes the unit and completes it, checking to make sure that the computer was built correctly during the entire process. This is based on preconfigured business process validations which could be done with the help of web services. Additionally, two processes, Repair and QA, take place for some units. For example, if a unit is damaged during the Input process, it goes to the Repair Process. Or, if QA randomly selects before its shipped, it will go through the QA process, where QA audits its production information. This becomes another candidate for enterprise and web services, as the case may be.
The process of demand forecasting that is done in Org.A, primarily happens on excel and access databases. The same is fed into DM in SAP. An ideal candidate for enterprise service for Org.A here could be to validate the existing demand with historical data that also measures seasonal variations in demand, checks the availability of goods from supplier systems before fulfilling an order. Maybe, this could be a long way off. But, the architecture an ESA architect lays down today will have far-reaching implications into the future.
Just because you have a platform ready for ESA compliance does not mean that the business would need it all the time and everywhere. it would be the SOA of the past when it was more esoteric and of little practical useage. With options like the above mentioned across multiple areas, it may make sense for some organizations, who rely on heavy customization, to create their own applications on top of their existing landscape and be adaptive for the future M&As intead of bying off-the-shelf packages and getting into a ESA-enabled complication in the future. Then again – it is a call Org.A has to take – to build or not to build – that is the question.