So, what does it take to implement SAP xMII? My clients and partners have asked the same questions over the past couple of years:

• How many people does it take and what are their required skill sets?
  
  
• What is the best way to approach a project?
  
  
• How do I coordinate with other teams?
  
  
• What interfaces/systems do I need?
  
  
• Which architecture is best for us?

To understand what it takes to achieve manufacturing integration and synchronization, you need to understand your business. Most likely, you execute every business process on both sides of the enterprise — the shop- floor and ECC sides. Your implementation project should do so as well.

There is no one-size-fits-all deployment strategy. Therefore, I have compiled the following deployment roadmap based on SAP ASAP methodology: project preparation, business blueprint, realization, final preparation, go-live, and support. I also based this roadmap on my own experience managing implementations and from projects that I witnessed or reviewed across different industries and throughout the SAP xMII community of partners and customers.

I will describe each step in the five-step process in the context of a hypothetical Quality Management (QM) scenario. Although you can use SAP xMII with other manufacturing systems, such as manufacturing execution systems and shop- floor automation applications, I’ll use QM in my example because it’s an area that is equally understood and important across industries.

QM Scenario

In my example, the company’s SAP QM and the Laboratory Information Management System (LIMS) system are not integrated, so the operator must manually enter in- spection readings from measuring equipment into the LIMS system. The QM analyst gets the results from the operator and manually re-enters them into SAP QM, which introduces redundancy, errors, and delays — for example, sometimes the QM analyst enters the results long after the products have shipped. This disconnect between the quality check on the shop floor and the quality management in the ERP system results in additional costs due to reworks and scrap and low customer satisfaction due to defective products.

The company needs to improve its quality inspection process and increase customer satisfaction by reducing the variation from customer’s specifications. This reduces cost by decreasing the amount of reworks and scraps, and improves visibility by delivering real-time quality notification of inspection lots results and displaying up-to-the- minute Statistical Process Control (SPC) analysis or out-of-spec parts and outliers.

The following is a roadmap for implementing SAP xMII, which allows you to quickly set up a framework and deployment strategy. When complete, SAP xMII allows the QM and LIMS systems to share data with each other.

Step 1. Prepare for the Projects

To ensure cross-functional and other team support for your project, it is useful to understand your company’s priorities and align your project goals accordingly. For instance, if one of the company objectives is lean manufacturing and supply chain optimization, your project goals should include enhancing inventory visibility, enabling flex scheduling, and improving forecasting. If quality and customer service are the main goals, your application should enable quality managers to monitor and respond to problems with actionable information. As you prepare for your project, keep in mind three key features that the project must have:

• Offer real benefits (i.e., it has to be meaningful)
  
  
• Have a manageable scope, so the team can get it done
  
  
• Have a business necessity (i.e., it has to solve a business problem, such as reducing rework and scrap). It’s easier to find project sponsors if you can prove its necessity and quantify its results, such as saving the cost of reworks.

Step 2. Map Business Processes and Applications

Any SAP xMII implementation has to start with defining the processes that enable the business. SAP xMII can simplify and optimize any process to a degree, but it doesn’t replace the know-ledge and understanding of the business intelligence behind the process.

To map the business processes, you need to understand the business objectives behind it, the data, and systems that enable it. Take, for example, QM. The business goal is to engineer quality into production and reduce defects. It requires applications such as Sample Management, Batch Management, Quality Inspection, Quality Analytics, and SPC. In addition, you can use interfaces to supportive systems, such as Integrated Problem Management, Corrective and Preventive Action (CAPA), and Customer Complaint Management.

The business process blueprints should map the process flow, applications, and roles that you need to complete the workflow. Next, create a high-level diagram, such as the one in Figure 1, to illustrate process workflow and roles you need to complete it. At this point, five to 10 steps are enough to describe the “as- is” process and enable everyone to have the same picture and work from the same assumptions. It also helps in the next step when the team needs to understand when and where to collect data.

Figure 1

Business process mapping

Next, a complete data mapping is required to determine what data elements the business process needs to gather, post, distribute, save, and display. This mapping starts with an inventory of the systems and applications that enable the business processes, as shown in Table 1. When the SAP xMII implementation is complete, QM uses it to integrate data from these systems and provide a comprehensive view on quality. Repeat this step for every business process in the project scope.

Step 3. Build the Team

The mix of functional and technical roles on the team is crucial. Understanding the business’ processes goes hand-in-hand with understanding your team requirements. An SAP xMII implementation requires both technical and functional knowledge. Cross-functional and technical skills are the foundation of a successful SAP xMII project.

The disparity of the shop-floor landscape with systems from different vendors built on different architecture and platforms calls for a wide range of technical and functional skills. These skills include:

• Technical Web and programming knowledge of concepts, such as JavaScript, HTML, Extensible Stylesheet Language Transformations (XSLT), and Cascading Style Sheets (CSS)
  
  
• Strong database skills, such as SQL and Oracle
  
  
• Knowledge of manufacturing systems, such as Manufacturing Execution Software (MES) and Supervisory Control and Data Acquisition (SCADA)

In addition, an SAP xMII developer should have a good understanding of SAP NetWeaver servers and components such as Portals. An SAP xMII Solution Architect (SA) or a functional lead should be familiar with ECC systems focused on the following modules: Materials Management (MM), Production Planning (PP), QM, and Plant Maintenance (PM). The SA role is needed for about 20-40% of the project time during the business process mapping, data analysis, and testing phases.

I recommend you start with a core team of SAP xMII developers with a solid knowledge of the product capabilities and flexibility and bring the functional skills into the team as needed. See the sidebar, “Project Team,” for details about each role on the team and the typical task each role performs. For more information about the project management aspect of an SAP xMII implementation project, see the sidebar, “Build the Project Plan and Governance Model.”

Step 4. Implement SAP xMII

It’s best to implement SAP xMII in three phases. Build the application and data interfaces, use rapid prototyping to test each business process, and optimize the SAP xMII architecture and connectivity.

Build the Application and Data Interfaces

Understanding the business process allows you to determine what application and interfaces are needed. Figure 2 demonstrates the QM inspection process that I want to build in SAP xMII. Looking at the diagram, you can see that the application interfaces are QM, LIMS, electronic test equipment, and possibly some homegrown applications.

Figure 2

QM inspection process workflow using SAP xMII

To build the application and data interfaces, follow these four steps.

Classify your applications (current and needed) to enable the business processes. Use the business process mapping you created in Figure 1 to determine all of the applications you need for your scenario — QM in this case. If you need additional applications, revisit the project scope and determine if adding the application is something you can do (using SAP xMII services to interface to the application) or if you need another approach, such as buying or building the application.

Use SAP xMII data services to connect to the target systems and gather the necessary data. You can build a common data interface layer to collect and share data across applications. SAP xMII has an extensive library of connectors that enable you to connect to systems on the shop floor and coordinate communication between ECC, the shop-floor system, and even third-party systems without the need to build or maintain a middleware or separate integration layer.

Define the business process triggers. Using SAP xMII business logic services (BLS), map the process data element and build its workflow. The system can trigger BLS transactions by receiving real-time inspection results to update the inspection lot results in QM, for example. SAP xMII also can notify production managers, customers, and sales reps if an issue occurs. I explained this in more detail in the “Quality Management and Continuous Improvement” section in my November 2006 article.

Using SAP xMII visualization services, build the user interface and the tools you need to interact with the processes. The system feeds the real-time test results and data that the SAP xMII data services collect into the business logic layer, BLS. BLS combines this and other data from SAP QM and PP, such as the inspection lot numbers and production order number (Figure 3). BLS analytics components examine the inspection results and update the SPC/SQC analysis chart. The system then updates the chart objects in SAP xMII visualization services with the results to deliver a real-time SPC analysis chart (Figure 4). It also feeds performance metrics at the portal and global KPI level (Figure 5).

Figure 3

Quality application and interfaces (Source: SAP)

Figure 4

SPC in-line analysis dashboard

Figure 5

Real-time divisional KPI view

Rapid Prototyping

A good practice is to start with one business process. Prototype SAP xMII with it to get the functionalities right, create a user test, and then finalize the user interface. For example, when you implement QM, start with the inspection lots list processes, and then the lot details and characteristics requirements. Finally, build the view and interface (Figure 6). Mark this milestone as completed and then move on to the next business process. Using this model, you can phase your project in rapidly deployed deliverables that keep the team motivated. Always test your model after each deployment, document lessons learned, and update the governance models.

Figure 6

Inspection lots list as a first step

Architecture and Connectivity

To optimize connectivity and reduce network traffic, you should place an SAP xMII server close to the shop- floor data sources. Refer to the “SAP xMII Deployment and Architecture” section of my November 2006 article for additional hardware requirements, depending on whether you have a single plant or multi-plant environment.

SAP xMII connectors optimize the communication between the target system and the SAP xMII server, as well as among different SAP xMII servers. Figure 7 illustrates the suggested multi-plant architecture. An SAP xMII server is installed in each plant to provide operational integration and visibility for production personnel. An additional SAP xMII corporate server is installed at a centralized location (the corporate data center) to aggregate and compare multi-site data and provide plant-to-plant matrix or divisional views and analytics for a complete balanced scorecard or best-of-class comparison.

Figure 7

SAP xMII multi-plant architecture (Source: SAP)

Another reason for installing an SAP xMII server at each plant is that most of the applications SAP xMII interacts with and connects to, such as control systems and process historians, are operational and required at each plant. Also, the data volume generated from some of these targets is very high and transferring it across the network may impact performance. Additionally, having an SAP xMII server at each plant allows you the option of running in a disconnected mode in case of wide area network (WAN) outage or ERP maintenance.

Step 5. Go-Live and Ongoing Support

After testing your prototypes, you must perform three checks to determine if your application is ready to face the users: the functional, technical, and go-live checks.

Functional check. The functional check investigates the applications to ensure that they meet the business process objectives. Functional users should perform this check. Another important step is to identify specific risk factors resulting from integrating legacy systems, such as continuity, modifications, maintenance, and support. Next, you need to identify and evaluate risk resulting from high volume requirements. This can identify problems with the required volume of data reads per minute and test whether the hardware architecture is the correct size.

Technical check. For the technical check the solution architect or the technical consultants perform a detailed analysis of technical integration by reviewing the implemented interfaces, focusing on performance, throughput, availability, and data consistency. Use SAP’s knowledgebase as a benchmark to identify showstoppers and improvement potential.

Go-live check. After the functional and technical checks you need to evaluate your hardware sizing based on project requirements, concurrent users, data, and document volumes. Next, follow the optimizations and configuration best practice of implemented systems, operating system, and database. 

Ongoing Operations and Support

Eventually, the users have to accept responsibility for the SAP xMII application and use it for the implementation to be considered successful. The best way to get your users’ buy-in is to demonstrate the impact and value of it on their day-to-day work. You should quantify the real change and its value by the numbers or more easily managed processes.

Even the best new system can die quickly if the business process owners do not embrace and use it. Another way to ensure that you sustain the change is to know your users’ needs and service them by continuing to perfect the solution and work out any bugs. Create an education and change management plan and involve your user. A good practice is to identify and encourage change agents in your user community. Involved and educated users reduce the overall cost of operations by enabling better maintainability, freed resources, and knowledge transfer among the user community.