Agile Information Systems for Mastering Supply Chain Uncertainty
Read this chapter. The main objective of this reading is to identify the different strategies and characteristics of supply chains. Pay attention to Figure 1 and the explanation for each. What types of companies do you think use Agile supply chains which deal with evolving and highly innovative products?
Implementation strategies for agile information systems
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.
Implementation strategies and challenges
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.