Agile Information Systems for Mastering Supply Chain Uncertainty

This section identifies three basic strategies for the implementation of agile information systems. The strategies involve different divisions of product configuration, process configuration and management of the order fulfillment among ERP systems, dedicated configurator software and SOA platforms.Therefore, we first will introduce the role of ERP systems, configurators and SOA to enable ICT mass customization.

Enterprise software (ERP)

An Enterprise Resource Planning (ERP) system is a standardized software package that combines functionality of multiple business functions into one integrated system. It is based on a single database and contains functionality to support the main business processes including production, distribution, warehouse management, sales, purchase and finance. The major advantage of ERP is that it provides a stable backbone for the registration and communication of information among business functions, and consequently ensures the timely and accurate availability for integrated business process management. As such, it helps to overcome fragmentation between organizational units (functional silos) and systems (island automation).

ERP has emerged in the early 1990s as a logical extension of the material requirements planning (MRP) systems of the 1970s and of the manufacturing resource planning (MRP II) systems of the 1980s. It has been advocated as essential means for implementation of Business Process Redesign in order to improve efficiency and customer service. Nowadays, ERP has become a de facto standard in many industries. For example, Aberdeen reported in 2008 that 86% of the manufacturing companies has implemented ERP.

Early ERP-systems were not primarily focused on the supply chain. Consequently, they failed to meet the demands in current dynamic supply chains. In a critical note, Rettig argues that the ERP concept of a single monolithic system failed for many companies: "But these massive programs, with millions of lines of code, thousands of installation options and countless interrelated pieces, introduced new levels of complexity, often without eliminating the older systems they were designed to replace". In a study of Akkermans et al., European supply chain executives address four key limitations of ERP systems in providing effective supply chain support:

• Their insufficient extended enterprise functionality in crossing organizational boundaries;
• Their inflexibility to ever-changing supply chain needs;
• Their lack of functionality beyond managing transactions; and
• Their closed and non-modular system architecture.
  

Akkermans et al. argue that the lack of modularity is the root cause for the other shortcomings.

In the research note "ERP is dead – long live ERP II", Gartner was one of the first who put the limitations of early ERP systems on the agenda. They defined ERP II as a transformation of ERP into next-generation enterprise systems, which are web based, open and componentised. The ERP industry has embraced this new philosophy and started to modularize their systems architectures, in particular by incorporating Service Oriented Architecture (SOA) platforms, e.g. SAP NetWeaver. Furthermore, ERP vendors included intelligent modules that go beyond transactions (especially Advanced Planning Systems and Business Intelligence). However, the monolithic nature is deeply embedded in ERP systems. It takes much time to unravel the big jumble of software code into a consistent and coherent set of components. Consequently, the componentizing of ERP is still in progress. This implies that, although valuable advances are accomplished, the basic limitations of ERP systems still exist.

ERP systems perfectly cover the demands of efficient supply chains that are characterized by stable business processes and low demand uncertainty. However, in supply chains with uncertain demand and high vulnerability of production and logistics processes, current ERP is experienced as an obstacle in achieving the required flexibility. The development towards modularized and service-oriented ERP is essential for the implementation of mass-customizable information systems. Such ERP systems ensure the availability of the software modules that, together, provide the desired functionality, including a specification of the interfaces. As such modularized ERP can provide a repository of building blocks that form the heart of mass customizable information systems.

Configurators

Configurators have emerged from the development of rule-based product design in the field of Artificial Intelligence. A well-known early application was R1, a product configurator for VAX computers. A product configurator is a tool that guides users interactively through specification of customer-specific products. Configurators generate specific product variants by combining sets of predefined components and specifying features according to permitted values. Next, they check the completeness and consistency of configured products based on rules that define the interdependencies between components or features. Product configurators are based on generic product models, which define the class of objects that can be configured.

Currently, configurators play an important role in responsive supply chains, which are characterised by high demand uncertainty and low supply uncertainty. They are widely used for product configuration to enable rapid response to customer demands. In interaction with the user, the software generates consistent and complete specifications of customised products, taking into account both customer's requirements (e.g. functional specifications and delivery conditions) and feasibility of production, sourcing and delivery. Along with the product specification, current configurators can produce commercial offers and draft contracts, and schedules and contracts for support and maintenance of the product. The software can be designed for use either by a sales representative of the supplier, or by a customer, e.g. through the internet. In both cases the configuration process results in a quick and effective order specification that can directly be entered into the production planning and scheduling systems.

Configurs can also be used to manage high uncertainties at the supply-side by supporting the rapid configuration of processes. This concept of process configuration is introduced by Schierholt, who applied the principles of product configuration to support process planning. Process configuration supports a rapid and consistent specification of the workflow that is needed to fulfill specific customer orders. For example, local deliveries from stock follow a different workflow than exports that are produced to order. Moreover, it supports reconfiguration of the workflow in case of unexpected supply events, e.g. components that were originally planned to be produced can be re-planned to be purchased.

Configurators can provide the configuration support as required in mass-customisable information systems. It helps to elicit the required functionality of specific instantiations of information systems building upon a generic information model.

Service-Oriented Architecture

Service-Oriented Architecture (SOA) is a software architecture where functionality is grouped around business processes and packaged as interoperable services. The aim is a loose coupling of services with operating systems, programming languages and other technologies, which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network to be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. Service providers publish web services in a service directory, service requestors search in this directory to find suitable services, bind to that service and use it, based on information from the directory and standardized procedures. So, SOA provides the technology that enables timely and flexible sharing of information demands. It is component-based by nature and widely acknowledged as the de facto standard for information integration. SOA enables the definition of components with standardized interfaces, a central repository of published web services and standardized procedures for selection and implementation of components.

A technical architecture based on SOA consists of three layers:

A business process management layer, coordinating the execution of business services: this is a functional integration layer that groups services from the underlying business service layer into business processes. The process services are typically implemented through generic enactment engines, that execute workflows defined in languages like BPEL or BPML. Following the workflow specifications, the enactment engines invoke services in the next layer. Services in the process layer can be rapidly configured or reconfigured using business process management (BPM) tools.

A business services layer, delivering information services to the business processes. The business services implement the information processing functions of the actual business processes. Business services may be either straightforward data registration or reporting services, or complex services based on extensive business logic. They may implement these functions directly, for instance applying the Business Rules Approach, or use application services that connect the business services to (legacy) information processing application systems.

A business application layer, executing the application logic and data storage. Applications are wrapped in application services, offering a standard web service interface to the business services, thus enabling enterprise application integration (EAI).

The advances towards Service-Oriented Architecture (SOA) has been very important to enable mass-customisation of information systems. It can provide a software platform that the web services can easily be plugged into, that can enact the execution of web services upon the occurrence of external or internal events, and that enables the exchange of information between the modules. Consequently, it can support to meet, in particular, the requirements concerning software modularity and information integration platform. As such, SOA can help to overcome the limitations of traditional ERP systems and achieve the required backend flexibility in agile supply chains. However, SOA does not include the knowledge required to specify services and to configure business processes as a sequence of services. Furthermore, the required software components must be available packaged as application-independent web services. So, even if a company applies SOA, important remaining challenges include the development of: i) generic information models that specify families of business processes and services, ii) tools that support configuration of specific business process and service architectures, iii) repository of software components software that are packaged as application-independent web services .

In sum, it can be concluded that enterprise software (ERP), configurators and Service-oriented Architecture (SOA) together could meet the requirements of ICT mass customisation (see Table 1). ERP can ensure the availability of the software modules in a repository of building blocks that form the heart of mass customizable information systems. However, the development towards modularized and service-oriented ERP is a crucial prerequisite to achieve this. Furthermore, configurators can provide the configuration support as required in mass-customisable information systems. It helps to elicit the required functionality of specific instantiations of information systems building upon a generic information model. Last, Service-Oriented Architecture (SOA) can help to meet, in particular, the requirements concerning software modularity and it provides an information integration platform.

Table 1. Main contributions of ERP, configurators and SOA to the requirements of ICT mass customization

Requirements ICT mass customization	Enterprise software (ERP)	Configurators	Service-oriented Architecture (SOA)
a. Generic information models		X
b. Modular software			X
c. Information integration platform			X
d. Configuration support		X
e. Component availability	X

The next section discusses some strategies on how the strengths of ERP, configurators and SOA can be combined to enable mass customisation of information systems.
Following Verdouw et al., three basic strategies can be distinguished to implement ICT mass customization by combining the strengths of ERP, configurators and SOA. Each includes a different division of product configuration, process configuration and management of the order fulfillment among dedicated configurator software, ERP systems and service-oriented middleware.

In the first strategy, process models are defined, configured and executed in a SOA-based process management platform, which intermediates between front- and back office systems, in particular product configurators and ERP systems for planning and scheduling.At this option, the functionality for product and process configuration is provided by different applications. Process configuration is done outside product configurators in service-oriented middleware.

Implementation of such an approach is complex. To mention some difficulties: the constraints arising from the actual availability of the required resources should be taken into account, as well as the dependences between configuration choices; it must be possible to inherit configuration choices from the product requirement definition to detailed process diagrams; and configuration choices must be translated into graphical diagrams. SOA-based process management platforms do not yet provide tool support for the configuration of process models in a manageable and user-friendly way.

Another important challenge of the first strategy is to find solutions for some technical problems that will arise when implementing process configuration in a SOA-based platform. For example, solutions have to be found to solve the problems arising from the redundancy of process knowledge as the defined in the process models of SOA-platforms and the hard-coded process logic in legacy systems. Furthermore, the incorporation of process model configuration into the run-time system will impact systems performance, in particular if the reference models are used by multiple organisations. In the latter case, also security will be an issue.

The second strategy is the inclusion of process configuration in dedicated configurator software.For this option, both product and process configuration are incorporated within one configurator and this tool is integrated with external planning & scheduling systems, either directly or via service-oriented middleware. The main challenge of this option is to manage the intensive interactions between the configurator and with external planning & scheduling systems, in particular in case of frequent reconfiguration of the workflow due to unexpected events. The most natural solution direction is to integrate both types of systems via service-oriented middleware. The implementation issues are similar to the first discussed implementation, except that the tool support for process configuration is not included in the SOA-based platform but in an external tool. Consequently, additional challenges include how to translate the output of the process configurator into a process model notation that can be interpreted by the SOA-based platform.

The third and last strategy is to include both product and process configuration into the ERP system and thus integrate all features (product configuration, process configuration and planning and scheduling) within one system. In this case, the ERP system is also the front office for customer interaction.There is no need for defining process models in SOA standards like Business Process Modelling Notation (BPMN) and some of the technical problems mentioned above can be solved easier. For example, the redundancy of process logic could be solved by using process models as the basis for system parameterisation. Furthermore, most ERP systems include functionality for product model definition and product configuration. This makes it easier to use process models for linking product configuration to the execution in back office systems. However, to do so, ERP systems should contain functionality for process modelling and the process models should be the basis for system usage. Many available ERP systems do not include such functionality. More importantly, ERP systems are not based on a modular approach, which is a fundamental precondition for the usage of process models to guide the workflow planning and execution in run-time information systems. At the same time, for many companies it is no realistic option to replace current systems with new flexible solutions is for many companies, among others because of the significant investments in legacy and the risks of losing stability. Because of these limitations, it might be preferably to keep the configuration of process models out of the ERP system.