Agile Information Systems for Mastering Supply Chain Uncertainty
| Site: | Saylor Academy |
| Course: | BUS606: Operations and Supply Chain Management |
| Book: | Agile Information Systems for Mastering Supply Chain Uncertainty |
| Printed by: | Guest user |
| Date: | Thursday, 3 April 2025, 10:07 PM |
Description
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?
Introduction
Mastering both demand and supply uncertainty is a key challenge for many companies. Markets are increasingly turbulent and also the vulnerability of production and logistics processes is growing. The management of uncertainty has been addressed as an essential task of supply chain management.For coping with the addressed uncertainties, Supply Chain Management (SCM) literature initially has focused on creating so-called lean supply chains that efficiently push products to the market. Lean supply chains build upon reduction of demand uncertainty, especially by product standardisation. Customers must choose from a fixed range of standard products that are made to forecast in high volumes. Business processes in lean supply chains can be highly automated by Enterprise Resource Planning (ERP) systems.
In the late 1990s, the then dominant approach of leanness was criticised more and more. It was argued that in volatile markets it is impossible to remove uncertainty. Companies therefore should accept differentiation and unpredictability, and focus on better uncertainty management. Agility was proposed as an alternative approach that aims for rapid response to unpredictable demand in a timely and cost-effective manner. It is founded on a mass customisation approach that combines the seemingly contradictory notions of flexible customisation with efficient standardisation. Efficient standardisation is realised by fabricating parts of the product in volume as standard components; distinctiveness is realised through customer-specific assembly of modules.
Until then, SCM focused on strategies for coping with demand uncertainty. Lee was one of the first who stressed the impact of supply uncertainty on supply chain design. Supply chains characterised by high supply uncertainty require the flexibility to deal with unexpected changes in the business processes. Disturbances of logistics, production or supply of materials should rapidly be observed and lead to process changes including re-planning and re-scheduling, purchasing new material, hiring alternative service providers, or negotiating new customer requirements.
Supply chains that are characterised by a high uncertainty of both demand and supply require a combination of responsiveness to changing demand and the flexibility to deal with unexpected changes in the business processes. Following Lee, we use the term agility to characterise these types of supply chains. In agile supply chains, demand requirements and supply capabilities, i.e. products and processes including resources, should be continuously attuned. Therefore, both front-office and back-office systems need to be flexible and smoothly integrated.
The main objectives of this chapter are to define the requirements to information systems in agile supply chains and to develop strategies for implementation of agile information systems. For the identification of requirements, the concept of mass customisation is applied to information systems.
The chapter first introduces a typology of supply chain strategies and the role of information systems in these strategies. Next, it focuses on information systems in the quadrant of agile supply chains. It is argued that these supply chains information systems should support an ICT (information and communications technology) mass customisation approach and the basic requirements for such an approach are defined. In the next section the role of ERP systems, configurators and Service Oriented Architecture (SOA) to enable ICT mass customisation is described. The chapter concludes with the introduction of 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 fulfilment among ERP systems, dedicated configurator software and SOA platforms.
Source: C.N. Verdouw, A.J.M. Beulens, T. Verwaart, and J. Wolfert, https://www.intechopen.com/books/supply-chain-management-new-perspectives/agile-information-systems-for-mastering-supply-chain-uncertainty
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Information systems and Supply Chain Management
Typology of supply chain strategies
Fisher introduced the idea that supply chain design should match the
degree of demand uncertainty. Fisher discriminates between functional
and innovative products. For functional products, having low demand
uncertainty, efficient or lean supply chains perform best. For
innovative products, that have a high degree of demand uncertainty,
flexible or agile chains are a better match. Lee extends Fisher's
analysis by adding the dimension of supply uncertainty. Lee
distinguishes between stable and evolving supply processes. Stable
processes are characterized by controllable production, mature
technology and settled industry. In evolving supply processes production
and technology are under development and more or less unpredictable.Lee
matches four supply chain types with characteristics of supply and
demand (see figure 1):
Figure 1. Supply chain strategies and demand and supply characteristics
- Efficient supply chains focus on cost reduction and match with low supply uncertainty - i.e. a controllable production process - and low demand uncertainty.
- Risk-hedging supply chains focus on pooling resources to reduce supply uncertainty; this type of chain matches with high supply uncertainty and low demand uncertainty.
- Responsive supply chains focus on flexibility through make-to-order process and mass customization; they match with low supply uncertainty and high demand uncertainty.
- Agile supply chains combine
risk-hedging and responsive strategies, aiming to cope with both high
supply uncertainty and high demand uncertainty.
The present
chapter focuses on agile supply chains. A firm operating in such a
supply chain lacks information about future demand and cannot reliably
plan the order fulfillment process. After having defined the current
position, two types of strategic options for dealing with the
accompanying uncertainty can be distinguished: i) uncertainty reduction
strategies that focus on decreasing the need for information, and ii)
strategies for better management of uncertainties that focus on
improving the information processing capacity.
Firstly, a firm
should determine whether reduction of uncertainty is possible and
desirable. Uncertainty reduction would imply a shift toward efficient,
responsive, or risk-hedging supply chains in the framework of Figure 1.
Reduction strategies aim to reduce differentiation by standardization
and to eliminate the sources of disruptions. Demand-related examples are
product standardization, sharing demand information exchange for
improved forecasting and establishment of long-term contracts.
Supply-related examples of reduction strategies are improved production
control, sharing supply information for synchronized planning,
cooperation with technology suppliers, hubs for supplier-managed
inventory, and production standardization e.g. by fixed batch volumes,
standard carriers, or fixed delivery schedules. Reduction of,
especially, demand uncertainty - for instance by product standardization
and reducing available product options – is not always desirable. In
particular this is not desirable for firms that find their market niche
in flexibly fulfilling specific customer needs.
Firms that cannot
sufficiently reduce supply and demand uncertainties must find ways to
manage the uncertainties. Such firms can consider possibilities for
uncertainty management, which leave differentiation and unpredictability
as is, but aim to manage it by better organization, maintaining close
relationships with suppliers and service providers, usage of advanced
decision support tools and better utilization of information.
The
mentioned strategies show that information systems are important means
for uncertainty reduction and uncertainty management. However, in
particular agile supply chains entails specific information system
needs, as discussed below.
Agile supply chains
In the
1990s Supply Chain Management (SCM) evolved towards an integrated
process approach in which the concepts of logistics management were
extended to incorporate the integration of firms in its supply chain. In
the beginning, the focus in Supply Chain Management (SCM) was very much
on so-called lean supply chains. The origins of lean manufacturing can
be traced to the Toyota Production System (TPS), which focuses on the
reduction and elimination of waste. Thus, lean
supply chains focus on efficient streamlined pipelines that push raw
material to the market in order to supply predictable demand in high
volumes at the lowest costs.
During the 1990s the focus on supply
chains as static physical pipelines was criticized more and more. In
definitions from the Supply Chain Management (SCM) literature, the
network character of supply chains was emphasized: "A Supply Chain is the network of organizations that
are involved, through upstream and downstream linkages, in the different
processes and activities that produce value in the form of products and
services in the hands of the ultimate consumer".
The enrichment
of the supply chain concept with the network dimension was no conclusive
answer to the criticisms on supply chains as static physical pipelines.
Also supply chain networks can be focused on the pushing products
efficiently to the ultimate customers. As a consequence, in the
beginning of this century there was an intensive debate in the SCM-field
on agility as an alternative for the then dominant approach of leanness. It was argued that a fundamental shift was required
in the dominant underlying approach. According to Christopher,
the lengthy and slow-moving "pipelines" have become unsustainable due to
the turbulence and volatility of current marketplaces. He suggests that
the key to survival in these changed conditions is through "agility",
in particular by the creation of responsive supply chains that are
market sensitive.
Agility can be defined as "using market
knowledge and virtual corporation to exploit profitable opportunities in
a volatile market place". Agile supply chains are
required to be market sensitive and hence nimble. The primary purpose of responsive chains is to respond quickly
to unpredictable demand in order to minimize stock outs, forced
markdowns and obsolete inventory. This thinking is based
on dynamics of business systems, which has been a major issue in
management research for a long time, while the concept of agility can be
traced back to Goldman et al.
From the debate emerged
that both leanness and agility are no mutually exclusive strategies. On a
strategic level it is a matter of strategic choice. There is no one best chain network design ('one size fits
all'), but companies continuously have to decide in which supply chain
they want to participate, which role they are able to play the best and
how they deliver added value in these networks. Furthermore, on an
operational level it is always a balancing process between push and pull
elements. Nevertheless,
there is a trend towards more agile supply chains because of increasing
demand and supply uncertainty.
Role of information systems in Supply Chain Management
Supply
chain management aims to manage the complex of business processes
performed by numerous interdependent supply chain actors as an
integrated whole.Information systems are vital to make the resulting
complex, frequent and inter-enterprise information flows manageable by
offering tools to automatically capture, process, transfer and
communicate information in the supply chain. They can support the
planning, control and coordinationof supply chains in the following
aspects:
- Communication of goals, plans and orders based on actual demand and supply information;
- Assurance of the required process execution by triggering the right activities and guiding the appropriate usage of resources and material (instructions);
- Continuous and chain-wide registration of monitoring information and effective alert mechanisms;
- Rapid and integrated decision-making based on aggregated and enriched monitoring information and information about external variables;
- Fast communication and implementation of the decided corrective and preventive actions.
As
a consequence, one can distinguish between the following roles of
information systems in Supply Chain Management:
- Inter-organizational technical communication infrastructures, including the Internet and Virtual Private Networks;
- EDI/XML based techniques for data exchange;
- Enterprise Application Integration (EAI): software to integrate the applications of individual chain actors, nowadays based on service-oriented architecture (SOA);
- Central, mostly web based information systems that are used by all involved supply chain actors to manage the basic information flow;
- Product configuration tools that help to specify customer specific orders in interaction with the customer within the process constraints (guided selling) and convert generated customer orders automatically into detailed production, sourcing or distribution orders;
- Point of Sales (POS) applications that help to replenish retail stocks on basis of actual consumer transactions;
- Integrated Planning Systems (CPFR: Collaborative Forecasting Planning and Replenishment), in which the planning of the involved companies is aligned;
- Enterprise software for production management, distribution, warehouse management, sales, purchase and finance (ERP systems);
- Early Warning Systems that continuously measure the process conditions and alert if there is serious risk based on an intelligent reaction on condition changes;
- Inter-organisational Management Information Systems that translate the basis process information into high-level management information about the realization of Performance Indicators, often in the form of management cockpits or dashboards;
- Demand Forecasting Models that help to analyse consumer behaviour e.g. on basis of Point of Sales data and predict future consumer demand in order to improve planning;
- Chain Process Simulation Models, that analyse the process behaviour in various levels of demand orientation and help to improve the fulfilment of consumer demand;
- Process configuration and implementation:
the adjustment of control variables and the supporting information
systems in order to support customer-specific process execution. Vital
enabling element is the ability to configure and reconfigure ICT
rapidly. Furthermore, ICT can support the required changes in human
behaviour, e.g. by stimulating problem awareness (diagnosis tools),
vision development (gaming and simulation) and intervention design.
A firm's information systems should match
the type of supply chain it operates in. For further analysis we
distinguish between front-office systems (coping with the demand side)
and back-office systems (coping with the supply side). Front-office
systems include order management, contract management, sales
configurator, demand forecasting, and customer relations management
systems. Back-office systems include resource planning and scheduling,
stock management, purchasing, and supplier relations management systems.
The type of supply chain determines the required flexibility of front-
and back-office systems:
Efficient supply chains require stable, straight-forward planning
systems for both front-office and back-office. The systems must be
well-integrated to reduce waste of resources. Back-office systems
support large volume production of standardized products based on
long-run forecasts. Front-office systems support efficient order
processing, long-run contracts and demand forecasts. Traditional ERP
systems cover the demands of efficient supply chains.
- Risk-hedgingsupply chains require the same type of stable front-office systems as efficient supply chains do. However, they require flexible back-office systems, integrated with production control systems and supplier's systems. Disturbance of production or supply of materials should rapidly be observed and lead to re-planning and rescheduling. The rigid planning and scheduling systems of traditional ERP systems may cause problems in this type of supply chain.
- Responsivesupply chains place high demands on the ability to combine fluctuations in demand and available supplies with respect to product specifications and lead times. The most common approach to organize responsiveness is mass customization in an assemble-to-order (ATO) production environment. This type of supply chain quickly responses to demand variability by efficient assembling of order-specific products from standard components. It requires stable back-office systems for efficient production of standardized components and rapid assembly. Traditional ERP systems can meet this demand. However, front-office systems require a flexibility usually not offered by traditional ERP systems. A responsive supply chain may require a more sophisticated sales configurator.
- Agilesupply chains require flexibility in both front-office and back-office systems. They demand flexible ERP in the back-office and sophisticated configurator and customer communications systems in the front-office. Tight integration is required between front-office and back-office and with systems of both suppliers and customers.
Requirements for information systems in agile supply chains
This
section focuses on the requirements for information systems in agile
supply chains. Therefore, it applies the concept of mass customisation
to information systems.
In agile supply chains, it must be
possible to easily set-up, connect and disconnect information systems
needed to achieve a specific value proposition. It must be possible to
design and instantiate new or adjusted supply chain configurations
rapidly and at low costs. The main challenge in achieving this is to
combine flexible customization with efficient standardization in the
design and implementation of the logistics information systems
introduced above. Mass customization is broadly advocated as a core
approach to balance these seemingly contradictory notions. It is a modular strategy that is intended
to accomplish efficiency by reusing standardized components, while
achieving distinctiveness through customer-specific assembly of modules. Mass-customisation
builds on four operational capabilities: i) common building blocks that
can be reused maximally, ii) unified architecture providing a structure
of the defined components that constrain possible variants, iii) a
technical platform for seamless integration of the building blocks, and
iv) configuration tools that support the elicitation of customer
requirements while considering the possible options.
ICT
mass customisation combines the seemingly contradictory notions of
efficient standard software and flexible customised software. It enables customer-specific assembly of information
systems from a repository of standard components. As such,
mass-customisable ICT can be positioned in the middle of a continuum of
standard packaged software and customised software. Software developers
pre-design and realise modules based on forecasted functionality.
Customers get their own ICT configuration, but constrained by the range
of available components, as defined in reference models for the
configuration of systems. These components could be supplied by
different software vendors, which allows for using best-of-breed
solutions in selecting and designing systems.
Following the
identified requirements for mass customisation systems, the requirements
for mass-customisable information systems are :
Generic information model: like product architectures in a mass
customisation approach, information models should be set up as generic
models, which define the class of architectures that can be assembled.
Additional complexity of generic information models is that they
comprise different interrelated model types including business process
models, product models, semantic data models and ontologies, and
information integration standards, e.g. eBusiness messages, web service
standards, RFID protocols, and coding standards.
Modular
software: modules in an ICT mass customisation approach must be
application-independent services, in which policy, input and output
data, and interfaces are well defined (product modularity). They should
not impose technical constraints on development of other modules
(process modularity). Furthermore, it should be easy to replace a
software module of provider A by a module of provider B, and it must be
possible to combine modules of different vendors (network modularity).
Information integration platform: a software platform is required that
the modules can easily be plugged into, that can enact the execution of
modules upon the occurrence of external or internal events, and that
enables the exchange of information between the modules. Contrary to
mass-customisable products, this platform has a virtual nature. It is
not tied to one place. Especially internet-based techniques enable
integration of modules that are located all over the world.
Configuration support: configuration of ICT elicits the required
functionality of specific instantiations of information systems building
upon a generic information model. Since information systems are
composed of many interacting components, ICT configuration must be done
for different levels of abstraction and different types of subsystems.
Consequently, configuring information systems includes many partial
configuration tasks that occur at different moments by different people.
The dependencies between these different tasks must be well
coordinated.
Component availability: the availability of
software modules that, together, provide the desired functionality,
including a specification of the interfaces. A specific characteristic
of ICT components is again the virtual nature. This implies that
components can be duplicated very quickly and at a negligible cost. On
the other hand, availability is dependent on service providers, because
users have access to the modules via an often complex information
infrastructure.
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.
Conclusions
The main objectives of this chapter were to
define the requirements to information systems in agile supply chains
and to develop strategies for implementation of agile information
systems.
The chapter has first introduced a typology of supply
chain strategies and the role of information systems in these
strategies.The type of supply chain determines the required flexibility
of front- and back-office systems. Efficient supply chains require
stable, straight-forward planning systems for both front-office and
back-office. Risk-hedging supply chains require the same type of stable
front-office systems as efficient supply chains do. However, they
require flexible back-office systems, integrated with production control
systems and supplier's systems. Responsive supply chains place high
demands on the ability to combine fluctuations in demand and available
supplies with respect to product specifications and lead times. Agile
supply chains require flexibility in both front-office and back-office
systems. They demand flexible ERP in the back-office and sophisticated
configurator and customer communications systems in the front-office.
Next,
the chapter has focused on information systems in the quadrant of agile
supply chains. It is argued that these supply chains information
systems should support an ICT mass customisation approach. ICT mass
customisation combines the seemingly contradictory notions of efficient
standard software and flexible customised software. It enables
customer-specific assembly of information systems from a repository of
standard components. Five requirements for the enhancement of ICT mass
customisation have been defined:
a) generic information model, b) modular
software, c) information integration platform, d) configuration
support, and e) component availability.
In the next section the
role of ERP systems, configurators and SOA to enable ICT mass
customisation is defined. None of these technologies completely satisfy
the defined requirements, but together they could enable ICT mass
customisation. ERP can ensure 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.
The chapter concludes with the
introduction of 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
fulfilment among ERP systems, dedicated configurator software and SOA
platforms. All of the strategies entail order-specific configuration of
the process model. The strategies differ in the technology to be used
for that purpose and the location of the knowledge required for process
configuration. The first strategy is to implement intelligent process
configuration in the middleware that mediates between front-office
systems (sales and product configurators) and back-office (ERP) systems.
This approach would require a considerable advancement of the
state-of-the-art in service composition. The second strategy is to
include process configuration in the product configurator, thus enabling
simultaneous configuration of product and process. This second approach
would require the extension of current product configurators. Since
process configuration depends on current and expected state of the
back-office, it would also entail extensive and frequent information
exchange between front-office and back-office systems. The third
strategy is to implement order specific process configuration in the
back-office ERP system. The latter strategy would avoid redundancy of
process knowledge, but many current ERP systems do not support the
modular process modelling approach and the dynamic configuration support
required to realise this strategy. The first or the second strategy
might be preferred depending on (among other factors) the extent of
supply uncertainty in a particular branch of industry.