Motorola Semiconductor Products Sector (SPS), based in Austin, Texas, is a leading manufacturer of semiconductors. The company is globally active, and employs over 26,000 people. As is typical for large corporations, the Materials Management (MM) processes at Motorola SPS were different across the various regions and organizations. Data integrity was severely lacking, and cycle time was measured in weeks. To rectify these problems, Motorola SPS decided to automate its material master maintenance. This functionality was introduced as part of a number of individual implementation projects, which were executed over a two-year period.
The individual projects also covered other key SAP R/3 functionalities, such as financial accounting, general ledger, procurement, bill of material (BOM), document and vendor management. Motorola SPS is currently live on SAP R/3 version 4.6c with approximately 8,000 international users. The company has implemented all or part of numerous components. In addition, SAP Business Information Warehouse (SAP BW) and SAP Advanced Planner and Optimizer (APO) have live implementations at Motorola. Future implementations will include Costing, Sales, Work Scheduling and Warehouse Management material views. The company will also be implementing the modules for Inventory Management, Product Costing, and Sales and Distribution. Motorola SPS is therefore well on the way towards complete Supply Chain Management with SAP products.
Decentralized approach for MM
Motorola SPS took a decentralized approach to the implementation of its MM strategy. The advantage of this strategy is that the people who are responsible for the data are able to use automated business processes to maintain their material master data with SAP`s WebFlow tool. The Motorola SPS material master implementation currently consists of the Basic Data 1 and 2, Purchasing, Purchase Order Text, MRP 1 – 4, General Plant Data/Storage, and Accounting material master views.
One of the key requirements of the first stage was the delivery of a web-enabled standard process for the maintenance of the MM Basic Data view, the functionality of which was to be geared towards the web system already in place at Motorola SPS. The company decided to use a custom IAC transaction (IAC = Internet Application Component) to capture data. In addition, web-enabled workflow was set up to validate and check data. The SAP Internet Transaction Server (ITS) was used as the web interface between the IAC and the SAP R/3 system.
The Motorola SPS IAC transaction consists of 80 ABAP screens, which support the MM document and BOM functionalities. Each of these ABAP screens has a corresponding web form, all of which were created and customized using the SAP Web Studio. The IAC assembles combinations of ABAP screens to create a request. Initially, 90 different requests were supported. The SAP R/3 System stores these requests in custom Z tables.
Once a user has created a material request, this request can be submitted for review and approval. Motorola SPS users determine who should approve the request based on assigned job functions and business rules. This process is automated and standardized by a customized SAP R/3 workflow. All 90 different requests use the same workflow. This workflow is web-enabled and is based on the same IAC and service files that the company uses to provide the data for review. The first stage of the software conversion had a tight schedule of just four months, and went live in the middle of August 2000 with around 3,000 users worldwide.
Standard developed for creation and change processes
In the first stage, Motorola SPS also implemented a standard process for create and change operations in MM. However, the data had to be manually transferred from the request to the SAP R/3 system. This manual input increased process time, led to errors, and consumed resources. As a result, the company wanted to transfer the data automatically from the approved request to the SAP R/3 system. However, the data needs to be absolutely correct for the SAP R/3 system to automatically accept it and create the basic data view for the material master.
In the second stage, Motorola SPS therefore enhanced the ABAP code used to enforce the business rules and check the data. These validation routines are now called automatically as the user navigates between the forms. If the system finds an error, the user is not allowed to leave the web form until the error is corrected. Additionally, new data elements and domains were added to many of the existing fields. Thanks to changes to the Data Dictionary and the enforcement of business rules, 70 percent of the request fields were being validated at this stage.
To ensure that the entered data always corresponds to the rules of the SAP R/3 Materials Management system, the validation processes were integrated in the request procedure. Motorola SPS developed an automated interface between the IAC transaction and the SAP R/3 system. This interface uses an ABAP RFC to perform the SAP R/3 MM validations. A further RFC is used to transfer the required data to the SAP R/3 “Create Material” transaction. The second stage of the software conversion went live in January 2001, with the automation interface following in September 2001. As a result of the additional data validation associated with automation, over 95 percent of the fields in the Materials Management system were then being validated. Motorola SPS therefore had a completely automated web process for material management.
Procurement views for brand new materials
For the procurement views, Motorola SPS developed two workflows that use the existing SAP R/3 MM functions. One of these workflows is used to create the procurement views for brand new materials. The second workflow is used to add or extend the procurement views for an already existing material. SAP R/3 MM is configured so that a Basic Data view must exist for a material before further views can be created. Therefore, the successful creation of a Basic Data view was defined as the event that triggers the workflow for creating the material from the procurement view. A Motorola SPS-defined role with the appropriate responsibilities ensures that the workflow task is delivered to the correct user for execution.
Both workflows (create and extend) use the SAP R/3 “Create Material” transaction. The users are presented with the SAP R/3 screens for creating materials when they execute the workflow. However, the procurement screens differ from plant to plant, but Motorola SPS found that many of the procurement material master attributes were the same in all the plants. To save the users from having to enter redundant data, Motorola SPS integrated an ABAP Batch Data Conversion (BDC) into the workflow task. This BDC saves the data entered for one plant, and automatically populates any additional views with this data. As a result, users can review the data in the views, and make changes before saving the views. This stage of the conversion went live in April 2002 with over 4,000 new users. Since then, the system’s automated Material Management process has allowed eight material master administrators to support the procurement material requirements of the entire SPS organization. These administrators process an average of 300 workflows each month.
One of the project deliverables of the final stage of the software conversion was to set up SAP APO functionality (SAP Advanced Planner and Optimizer). This required maintenance of the MRP views (MRP: Material Requirements Planning). Based on the MM workflow design for procurement from the previous stage, a separate workflow was developed to create the MRP views. This workflow also makes use of the existing SAP R/3 “Create Material” transaction. It is triggered as soon as a Basic Data view is created for a planned material type. This final step in the software conversion went live in mid-August 2002 with around 400 new SAP R/3 users.
Consistent and reliable
The MM web request process is executed at Motorola SPS on average 630 times a month, and supports an average of 1100 material creations per month. Compared to the original system, the company was able to reduce the average cycle time required for creating a Basic Data material view by 66 percent. In addition, web request rework rates were also considerably reduced, even though the system became increasingly complex with every successive development step.