ArchiMetal Transformation Overview

The organizational structure of ArchiMetal has already been introduced in Figure 1. Figure 9 identifies key services ArchiMetal provides to its customers through its DCs, along with the business processes that realize these services.

DCs act as profit centers, and enjoy significant autonomy within the bounds of mandatory ArchiMetal policies and procedures. They add value through customer intimacy and their ability to do business in their designated regions. Therefore, DCs adapt their business processes to specific regions and customer segments, which precludes standardization across ArchiMetal.

Figure 9: Customer Services Provided by DC Benelux

Figure 10 portrays the inter-dependencies between the key business processes related to sales. Figure 11 presents the details of information flows underlying these processes.

Figure 10: Inter-Dependencies between the Key Sales Processes in DC Benelux, PC, and HQ

Figure 11: Most Important Information Flows between the Units

In this figure, DCs receive customers’ orders. HQ assesses the risk involved in some of these orders. PC receives aggregate orders from DCs for use in production.

The Application Cooperation view in Figure 12 shows the information flows between applications in the HQ, DC Benelux, and PC. Figure 12 is an ArchiMate application landscape diagram that shows the usage of applications by different departments or business units within ArchiMetal.

DC Benelux uses its own customer data management applications for maintaining customer data, contract creation, and printing, and for supporting credit risk analysis. The order management application at DC Benelux administers orders and exchanges data with a PC system for order management. As noted earlier, only aggregate order information is exchanged, with no information about individual orders. The DC also uses its own shipping and invoicing applications, along with a financial application that manages receivables.

Figure 12: Application Landscape of ArchiMetal

In this figure, integration between the different applications is enabled with an Enterprise Application Integration (EAI) bus. Customer-related data is not standardized at the company level.

PC has its own application for managing DC orders, which communicates via the EAI bus with the DC’s order management applications. The PC uses an application to invoice distributors for the bulk orders fulfilled. The PC also has an ERP solution with components for inventory and materials management, production planning, and financial management, including the maintenance of a general ledger.

The DC order management application integrates with the ERP solution so that its users can verify whether there are enough finished goods or products on hand to fulfill a bulk order, and to schedule additional production as necessary. Once there are enough products on hand to complete a bulk order, the order management application works with the shipping application to initiate delivery.

The EAI bus manages communication between the applications. Since there is no standard format for customer data, unique transformation logic exists for each pair of applications that must work together to serve customers. The IT organization must perform extensive specification, development, and quality assurance across many modules of code for even the simplest of data enhancements. This makes it difficult for ArchiMetal to respond to new customer requirements or other changes in the business environment.

The ArchiMetal IT infrastructure includes a Wide Area Network (WAN) that connects the HQ, PC, and the DCs, a corporate data center at HQ, a manufacturing data center at the PC, and smaller computing facilities for local file servers and applications at each DC. Each data center has a data center network, and each site has a Local Area Network (LAN). Figure 13 shows aspects of the corporate data center, which is based on a mainframe and additional distributed servers. The mainframe is divided into multiple partitions. Each partition consists of hardware and software, including a Database Management System (DBMS) and reliable messaging queuing software, which provide services to applications. The distributed servers run UNIX^® operating systems and DBMS software, and provide additional services, including centralized authentication and authorization for a variety of applications on ArchiMetal networks.

Figure 13: Key Aspects of the ArchiMetal Corporate Data Center Infrastructure

The target Enterprise Architecture adds a Customer Service department to ArchiMetal HQ (Figure 14). This department defines the structure of customer master data and manages a central customer database, including overseeing how that data is shared with ERP processes and systems. Customer Service regularly audits the quality of customer data and works to improve processes that promote data quality. The department also has a team of information analysts that analyze the customer data to inform marketing, sales, and service activities across the company. The Customer Service department also manages a new service to track customer orders from initial submission to payment, and assists DCs with collections of delinquent accounts receivable. Most importantly, the Customer Service department operates a consolidated Contact Center to assist and inform customers.

These changes allow the DCs to concentrate on sales while taking advantage of improved customer data and analytics, rather than collecting and managing customer data and dealing with routine questions and issues. In addition, they give HQ greater visibility and control over DC pricing and credit practices as sales contracts are negotiated.

Figure 14: Changes to ArchiMetal Organization Structure, including New Department: Customer Service

The target Enterprise Architecture also centralizes order data and provides integrated IT support for order management through the CRM system. This makes customer behavior more visible across ArchiMetal and makes it easier to keep customers informed about the progress of their orders. In addition, centralized customer data and analytics improves sales forecasting, and enables continuous improvement of the product portfolio as well as production and procurement plans based on customer behavior.

The target Enterprise Architecture also improves coordination of order processing. Instead of transmitting aggregated orders, DCs transmit individual orders to the PC, which monitors and publishes a status for each of them. This speeds fulfillment of customer orders, and eases accommodation of special requests such as urgent orders. Figure 15 shows the simplified information flows that enable these improvements. Figure 16 provides a high-level view of the key elements of the target Enterprise Architecture, which also pinpoints enhanced coordination and alignment between the business processes as well as with their application support.

Figure 15: Relevant Information Flows between Business Units

In this figure, new flows and functions are marked with bold type or red lines.

Figure 16: Overview of the Key Changes in the Overall Enterprise Architecture of ArchiMetal

This figure shows the alignment between new processes, services, information flows, and applications. These changes are elaborated throughout this section.

As illustrated in Figure 17, ArchiMetal introduces an Order information service. Customers can now choose the events about which they are notified, as well as the types of notifications they receive, such as emails or Electronic Data Interchange (EDI) messages. Figure 18 shows in more detail the realization of this service by a new process.

Figure 17: New Customer Service Enables Real-Time Monitoring of Customer Orders

Figure 18: New Processes and their Inter-Dependencies with Existing Processes

The fact that all processes handling customer orders deal directly with individual customer orders allows for better coordination between them, and also allows more precise and efficient tracking of each customer order’s status.

The target architecture introduces CRM and customer order monitoring applications. These applications share customer data through an EAI bus.

The central HQ CRM system replaces the functionality of previous, per-DC customer data management applications. Now, DCs have limited edit rights over customer data, since assuring the correctness and uniqueness of customer entries is the responsibility of the Customer Service department within HQ.

The CRM system also manages customer orders and thus replaces regional order management applications and the Sales order management application used by the PC.

Figure 19: New Application Landscape with the CRM System Sharing Centralized Customer Data through an EAI Bus

In Figure 19, the customer order monitoring application implements the Order information service.

To enable the sharing of customer master data, new interfaces are defined and implemented on the EAI bus. For the purposes of order management, the CRM system interfaces through the bus with ERP components. The production and shipping order management used by the PC includes information about individual customer orders.

The DC invoicing applications now use shared master customer data managed by the CRM system, instead of relying on customer data stored in the separate databases owned by each DC. Reports on total customer debt are produced by invoicing applications in conjunction with the CRM system, which therefore requires new interfaces with the EAI bus.

Finally, the new Customer order monitoring application automates the Order Information service described above in the target Business Architecture. It makes key functionality directly available to customers with a web user interface. This application combines data from the HQ central CRM system and the regional shipping applications, and interfaces with them via the EAI bus (Figure 19).

Compared to the baseline (Figure 13), the target infrastructure has similar components and delivers the same types of services. Additional application and database servers are added to the corporate data center for the new CRM application.