View
213
Download
0
Category
Preview:
Citation preview
Business Information SystemsBusiness Information Systems
Adam Adam WasilewskiWasilewski, PhD, PhD
Management Information Systems Management Information Systems
DefinitionsData
Origin: Latin, plural of datum
• factual information (as measurements or statistics) used as a basis for
reasoning, discussion, or calculation,• information output by a sensing device or organ that includes both useful
and irrelevant or redundant information and must be processed to be
meaningful,• information in numerical form that can be digitally transmitted or
processed.
DefinitionsInformation
• the communication or reception of knowledge or intelligence,
• knowledge obtained from investigation, study, intelligence, news, facts, data or instruction,
• the attribute inherent in and communicated by one of two or morealternative sequences or arrangements of something (as binary digits in a computer program) that produce specific effects,
• a signal or character (as in a communication system or computer)representing data,
• a quantitative measure of the content of information.
DefinitionsSystem
• a regularly interacting or interdependent group of items forming a unified whole,
• a group of parts that together perform one or more vital functions,
• a group of devices or artificial objects or an organization forming a network especially for distributing something or serving a common purpose (as a telephone system, a computer system).
DefinitionsManagement
• the acts of getting people together to accomplish desired goals and objectives,
• includes: – planning,
– organizing,
– staffing,
– leading,
– directing,
– controlling,
• an action to facilitate the production of useful outcomes from a system.
DefinitionsManagement – interesting literature ☺
• Sun Tzu, The Art of War, the 6th century BC (recommendation for
„managers” to be aware of and acting on strengths and weaknesses of
both a manager's organization and a foe's),
• Niccolò Machiavelli, The Prince, 1513 (recommendation for using fear, but
not hatred, to maintain control),
• Adam Smith, The Wealth of Nations, 1776 (recommendation for efficient
organization of work through specialization of labour),
DefinitionsInformation System
• a combination of information technology and people's activities using that technology to support operations, management, and decision-making,
• helps to control the performance of business processes,
• a special type of work system including humans and/or machines that perform work using resources to produce specific products and/orservices for customers,
DefinitionsInformation System - activities
Information system’s activities are devoted to processing information:– capturing,
– transmitting,
– storing,
– retrieving,
– manipulating,
– displaying.
DefinitionsManagement Information System
• a system or process that provides information needed to manage organizations effectively,
• a subset of the overall internal controls procedures in a business (including people, documents, technologies, and procedures) used to solve multi-level business problems,
• a system used to analyze other information systems applied in operationalactivities in the organization,
Genealogy of IT in managementTimeline of management-oriented IT tools
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
IT tools for management
MSS
DSS
ES
EIS
AIS
IMSS
TPS
STRATEGIC
PLANNING
TACTICAL
CONTROL
OPERATIONAL
CONTROL
TRANSACTIONAL
PROCESSING
IT tools for management
Decision making
Type of
decisionOperational Tactical Strategic
Structured
Semi-structured
Unstructured
IT tools for management
Type of
decisionOperational Tactical Strategic
Structured
Semi-structured
Unstructured
MSS
ES
AIS
TPS MSS
MSS DSS
ES
EIS
AIS
IMSS IMSS
IMSS MSS DSS IMSS
EIS
Transaction Processing Systems
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
Transaction Processing Systems Introduction
Transaction processing systems (TPS) - a type of system intended to
automate the handling of business activities or transactions data. TPS do
not support decision making.
The goal of TPS development is to improve transaction processing by
speeding it up, using fewer people, improving efficiency and accuracy,
integrating with other information systems or providing information not
previously available.
Management Support Systems
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
Management Support Systems
Management Support Systems (MSS) - a type of system intended to extend the information retrieval capabilities of the end-users with query and analysis functions for searching a database, generating what-ifscenarios, and other such purposes.
MSS cover usually single business area (e.g. finance, distribution, production) and provides:
• data acquisition and processing,
• simple analysis,
• pre-defined reporting.
Decision Support Systems
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
Decision Support Systems Introduction
Decision support systems (DSS) - a type of system intended to support
business or organizational decision-making activities.
DSS cover areas of the management, operations, and planning levels of an
organization and help decision makers to compile useful information from
a combination of raw data, documents, personal knowledge, or business
models to identify and solve problems and make decisions.
Expert Systems
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
Expert Systems Introduction
An Expert System (ES), a software (traditional and/or supported by artificial intelligence) that attempts to solve a problem, or clarify uncertainties where normally one or more human experts would need to be consulted.
Expert Systems are used for the complex areas where a simple traditional algorithm is insufficient to provide the proper solution, e.g. in accounting, process control, financial service, production, human resources management etc.
Expert Systems Accurateness
Basic ES use true/false logic to evaluate data.
More extended systems are capable of performing some evaluation,
taking into account real-world uncertainties, using fuzzy logic.
ES do not typically give a definitive answer, but provide a probabilistic
recommendations.
Expert systems can generate an incorrect answer if in the same situation the
human decision-making expert has committed the same error.
Executive Information Systems
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
Executive Information Systems Introduction
An Executive Information System (EIS) - a type of system intended to
support the information and decision-making needs of top executives. It
provides „user friendly” access to internal and external information that
influences the strategic goals of the organization.
EIS offer reporting and drill-down capabilities (e.g. break down data for
detailed reports for products, regions, salespersons etc.).
Executive Information Systems Advantages
• interface easy-to-use for upper-level executives, high computer
experience is not required in operations,
• provide timely delivery of company summary information with the
possibility of drill-down,
• easy-to-understood information presentation,
• data filtered for management purposes,
• provide timely, relevant and complete information for top executives.
Executive Information Systems Disadvantages
• depend on information from external systems,
• functionality limited by design and implementation,
• may provide too much information for some managers,
• hard to quantify benefits (ROI),
• high costs of implementation,
• may work slowly with big sets of data,
Executive Information Systems Business Intelligence
EIS are nowadays frequently called Business Intelligence (BI) systems that
include reporting, online analytical processing, analytics, data mining,
business performance management, benchmarking, text mining, and
predictive analytics.
BI provides historical, current, and predictive views of business
operations.
Artificial Intelligence Systems
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
Artificial Intelligence Systems Introduction
An Artificial Intelligence System (AIS) – a type of computer-based system
intended to behaviour as „intelligent” as a human.
Artificial Intelligence (AI) - the capability of a machine to perform functions
that are normally associated with human intelligence, such as reasoning and
optimization through experience.
Areas of AI activity include: expert systems, natural language understanding,
speech recognition, robotics etc.
Artificial Intelligence Systems Turing test
The Turing test, proposed by Alan Turing in 1950 - a test of machine's ability to show its intelligence.
The procedure of Turing test:
– a human judge engages in a natural language conversation with one human and one machine, each of which tries to appear human
– participants are placed in isolated locations, so they do not see each other,
– the conversation is limited to a text-only channel such as a computer keyboard and screen
– the machine is said to have passed the test if the judge cannot reliably point the machine.
Artificial Intelligence Systems AI test outcomes
The classes of outcome for AI test:
• optimal, it is not possible to perform better (e.g. draughts),
• strong super-human, performs better than all humans,
• super-human, performs better than most humans (e.g. chess, nearing
strong super-human),
• sub-human, performs worse than most humans (the most of everyday
tasks performed by humans).
Artificial Intelligence Systems AI areas
– computer games - computers programmed to play games (e.g. chess and draughts),
– expert systems – computers programmed to support decisions making in real-life situations (e.g. management decisions),
– natural language - computers programmed to understand natural human languages,
– neural networks –computers programmed to simulate intelligence physical connections that occur in human brain,
– robotics - computers programmed to see and hear and react to other sensory stimulation.
Integrated Management Support Systems
1965: Transaction Processing Systems (TPS)
1970: Management Support Systems (MSS)
1975: Decision Support Systems (DSS)
1980: Expert Systems (ES)
1980: Executive Information Systems (EIS)
1985: Artificial Intelligence Systems (AIS)
1990: Integrated Management Support Systems (IMSS)
Integrated Management Support SystemsIntroduction
Systems integration - the process of linking together different computing
subsystems and/or software applications physically or functionally.
Information systems in the organization may be integrated in several
levels:
• Sub-enterprise Integration,
• Single-site Integration,
• Multi-site Integration,
• Distributed Enterprise Integration.
Integrated Management Support SystemsSub-enterprise Integration
Sub-enterprise Integration – the functionality of the
integrated subsystems is limited to a homogeneous area,
usually at a single site:
• Design integration (Computer Aided Design - CAD/Computer
Aided Manufacturing - CAM),
• Material Requirements Planning (MRP),
• Process Integration (Numerical Control - NC, Computerized
Numerical Control - CNC).
Integrated Management Support SystemsSingle-site Integration
Single-site Integration – a complete functional integration of
the united business processes, manufacturing processes and
product realization to gain common goals, usually at a single
plant (automated factory):
• Integrated Product/Process Development (IPPD) teams,
• Enterprise Resource Planning (ERP),
• Flexible Manufacturing Systems,
• Computer Integrated Manufacturing (CIM).
Integrated Management Support SystemsMulti-site Integration
Multi-site Integration – a complete integration of large
enterprises in heterogeneous systems through out their
enterprises:
• Electronic Data Interchange (EDI),
• Exterprise Resource Planning (ERPII),
• Technologies Enabling Agile Manufacturing (TEAM),
• Extranets.
Integrated Management Support SystemsDistributed Enterprise Integration
Distributed Enterprise Integration – complete supply chains and distribution chains, integration of all members to fulfil a common goal through product realization (extended integration) and/or virtual enterprises, dynamically created and dissolved on an as-needed basis (virtual integration):
• Flexible Instant Partnering,
• Seamless Distributed Virtual Collocation,
• Virtual Electronic Alliance,
• Virtual Organizations.
The Evolution of Resource Planning Systems
Timeline of resource planning systems:
• late 1950’ – Inventory Control (IC)
• 1960’ and 1970’s – Material Requirement Planning (MRP)
• 1970’ – Closed Loop Material Requirement Planning (MRP-CL)
• late 1980’ – Manufacturing Resource Planning (MRPII)
• 2000’ – Enterprise Resource Planning (ERP)
• late 2000’ – Exterprise Resource Planning (ERPII)
Inventory Control SystemsBasics (1)
Inventory Control - a process for keeping track of objects or materials.
Inventor Control System - a set of hardware and software based tools
that allow you to automate the process of inventory tracking.
Functionality of the oldest IC systems covered:
• The maintenance of item status (on-hand and on-order)
• Recording of stockroom transactions
• Reporting of stock status
Inventory Control SystemsBasics (2)
As a result of evolution IC systems their functionality was expanded by
tracking of:
• reservation’s status against an item,
• purchase order,
• production order,
• operations status of production order,
• work centre load.
Inventory Control SystemsInventory types (1)
According to APICS inventories can be divided into several types:
• raw materials – are converted into useable parts during manufacture process; purchased items or extracted materials that are converted into components and products through manufacturing,
• work in process – goods in various stages of completion throughout the plant, including all material that has been released for initial processing and processed material waiting for a final inspection as finished inventory,
• finished goods – goods on which all manufacturing or service operations have been completed; they are available for delivery to the customer,
Inventory Control SystemsInventory types (2)
• distribution – inventory located in the distribution system that is separate
from manufacturing inventory; they includes items in transit and in
storage that are awaiting delivery to a customer,
• maintenance, repair, and operating supplies (MRO) – items used to
support general operations and maintenance, such as spare parts, and
consumables used in the manufacturing process and supporting
operations.
• service parts – modules, kits, components, and individual parts used to
replace an original without modification.
Material Requirement Planning SystemsBasics (1)
Material Requirement Planning (MRP) – a set of techniques that uses bill
of material data, inventory data, and the master production schedule to
calculate requirements for materials.
The method was developed in the 1960s by Joseph Orlicky who studied
the TOYOTA Manufacturing Program and described it in the book entitled
The New Way of Life in Production and Inventory Management.
MRP was implemented in 150 companies before 1975, and in about 8000
in 1981.
Material Requirement Planning SystemsBasics (2)
In the 1970s the expansion of MRP was supported by non-commercial
(e.g. APICS) and commercial organisations (IBM, ICL).
APICS (the American Production and Inventory Control Society), founded in
1957, a not-for-profit educational organization consisting of 60,000 members
in the production/operations, materials, and integrated resource
management areas.
IBM offered in the 1970s application packages (PICS – Production Information
and Control System and COPIeS – Communications Oriented Production
Information and Control System) with implemented MRP.
Material Requirement Planning SystemsThe Architecture of MRP systems (1)
MRP systems cover three major areas:
• Inventory control (INV)
• Bill of Materials (BOM)
• Material Requirement Planning (mrp)
To avoid misunderstanding the acronym MRP is used for Material
Requirement Planning systems and the acronym mrp for a module
(subsystem) of material requirement planning.
Material Requirement Planning SystemsThe Architecture of MRP systems (2)
BOMBOM
mrpmrp
INVINV
information flow
optional information flow
Material Requirement Planning SystemsBill of Materials
The Bill of Materials subsystem provides information about lists of the
raw materials, sub-assemblies, intermediate assemblies, sub-components,
components, parts and the quantities of each needed to manufacture an
end product.
BOM has a hierarchical nature where the top level represents the final
product and lower levels represent a sub-assemblies or materials.
BOMBOM
Material Requirement Planning SystemsBill of Materials – an example of BOM structure
A
(FINAL
PRODUCT)
B
(sub-assembly)
F
(sub-assembly)
C
(material)
D
(sub-assembly)
E
(material)
G
(material)
H
(material)
E
(material)
G
(material)
I
(material)
BOMBOM
Material Requirement Planning SystemsBill of Materials – parts (items)
Each part (item) in the BOM should be described (at least) by:
• part (item) number – a unique identificator that may be generated randomly or significantly (with additional description, e.g. source, material, shape)
• part (item) name – as precisely as possible,
• basic unit of measure.
The rest of information that can be stored in BOM (e.g. product line, group, type, location, size, weight, inventory information, price, costs) is not usually used in the simple MRP systems.
BOMBOM
Material Requirement Planning SystemsBill of Materials – „parent” and „child” relationship
The hierarchical view of the product’s structure determines a relationship
(„parent” – „child”) between items on different levels.
„Children” are the objects (items, sub-assemblies, materials) that are
assembled together to make a „parent” object (final product, sub-
assembly).
To provide full information it is important to point how many units of
„children” items are necessary to produce one unit of „parent” item.
BOMBOM
Material Requirement Planning SystemsBill of Materials – an example of „parent” and „child”
relationship
To produce one unit of item B we need 5 units of item E and 0,02
unit of item F.
BOMBOM
Material Requirement Planning SystemsBill of Materials – an extended example of BOM
A
(FINAL
PRODUCT)
B
(sub-assembly)
F
(sub-assembly)
C
(material)
D
(sub-assembly)
E
(material)
G
(material)
H
(material)
E
(material)
G
(material)
I
(material)
LEVEL 0
LEVEL 1
LEVEL 2
LEVEL 3
-
um(A)
3
um(B)
0.5
um(C)
1
um(D)
5
um(E)
0.02
um(F)
1
um(G)
2
um(I)
1
um(G)
2
um(H)
0.8
um(E)
BOMBOM
Material Requirement Planning SystemsBill of Materials – displaying the BOM: explosion
Explosion is a way to display the BOM from the top to the bottom.
It can be divided into three categories:
• Single level explosion that displays the immediate component parts
(children),
• Indented explosion that displays parent on left-hand side and each
additional level indented farther to the right,
• Summarized explosion that shows an indented explosion into total
quantity order or part number order and adds together the total
requirement for each part number.
BOMBOM
Material Requirement Planning SystemsBill of Materials – examples of explosion (1)
Part number Quantity
# G 1
# H 2
# E 0,8
Single level explosion of item #D
Part number Quantity
# G 1
# I 2
Single level explosion of item #F
BOMBOM
Material Requirement Planning SystemsBill of Materials – examples of explosion (2)
Indented explosion of item
#A
BOMBOM
Material Requirement Planning SystemsBill of Materials – examples of explosion (3)
Summarized explosion of
item #A
BOMBOM
Material Requirement Planning SystemsBill of Materials – displaying the BOM: implosion
Implosion is the second way to display the BOM - from the bottom to the
top.
It can be divided into three categories:
• Single level implosion that displays the immediate parent of a given
component,
• Indented implosion that displays all the parent on given component, used
to detect commonality of parts in different assemblies
• Summarized implosion that shows an indented implosion into total
quantity order or part number order and adds together the total
„parents” of each part number.
BOMBOM
Material Requirement Planning SystemsBill of Materials – phantoms
Phantoms –a coding and structuring technique used primarily for
transient subassemblies. The phantom bill represents an item that may
not exist physically but is treated as an accounting unit.
Phantoms cost and lead time are always zero. They are transparent to
MRP and completely ignored during planning.
Based on the Master Schedule and phantoms we can generate (calculate)
requirements for every version of the final product.
BOMBOM
BOMBOM
Material Requirement Planning SystemsBill of Materials – examples of part descriptions
Part number:
XX – code of product type (e.g. 47 – cartridges)
YYYY – random number
47-8299
Blue Ink Cartridge
200ml
Part number
Part name
Part unit setPart number:
XX – code of product type
YYMM – year (YY) and month (MM) of production
(e.g. Sept2010)
Z – type (e.g. 7 – Ink)
AA – colour (e.g. 16 - blue)
BBB – capacity (200)
BOMBOM
Material Requirement Planning SystemsBill of Materials – an example of BOM with phantoms
To create individual Bills of Materials we need 12 different product structures:
(2 engine types * 3 colour types * 2 specification types).
Material Requirement Planning SystemsBill of Materials – an example of BOM with phantoms
If we have to produce 1000 cars we may base on the percentage figures
associated witch each option (e.g. from statistical data from past sale) and
generate requirements for:
•0,4 * 0,5 * 0,7 * 1000 = 140 basic version of silver cars with 100KM engine
•0,6 * 0,2 * 0,3 * 1000 = 360 top version of red cars with 140KM engine
•…
BOMBOM
BOMBOM
Material Requirement Planning SystemsEngineering BOM vs. Manufacturing BOM
Engineering BOM (from the designer point-of-view) may be different from
Manufacturing BOM (from the production point-of-view), e.g. some materials
have to be mixed before they will be mixed with the third one.
A
(FINAL
PRODUCT)
B
(sub-assembly)
F
(sub-assembly)
C
(material)
D
(sub-assembly)
E
(material)
G
(material)
H
(material)
E
(material)
G
(material)
I
(material)
Engineering BOM Manufacturing BOM
Material Requirement Planning SystemsBill of Materials – interactions
In the MRP systems BOM module may interface with:
• Inventory Control that uses part master data to identify inventory items,
• Material Requirements Planning (mrp) that uses product structure to
translate independent into dependent demand.
Independent demand - a demand that is not based on the demand for another
item (usually concerns final products), it can be calculated from customer
orders, sales plan or forecasted.
Depended demand - a demand that is based on the demand for another item
(usually concerns raw materials and semi-finished products), it can be
calculated by MRP system.
BOMBOM
Material Requirement Planning SystemsInventory Control
The basic transactions in the INV subsystem:
• incoming:
– receipts management,
– identification by part numbers,
– purchased items management,
– manufacturing items management,
• outcoming:
– issues management (raw materials, component parts and assemblies):
– individual orders,
– sets of components (for manufacturing/final customer),
– transfers from one stores location to another or between warehouse,
• reporting (e.g. ABC class reports with quantities and/or value)
INVINV
Material Requirement Planning SystemsInventory Control – interactions
In the MRP systems INV module may interface with:
• Bill of Materials (obtaining product structures to prepare kitting list),
• Material Requirements Planning (mrp) that uses inventory balances to
calculate net requirement and actualizes inventory balances after
requirements planning.
INVINV
Material Requirement Planning Systemsmrp
Basic functions of the mrp module:
• getting the independent demand,
• receiving of product structures from BOM module,
• calculating the depended demand from the independent demand,
• receiving inventory balance from INV module,
• calculating net requirements,
• comparing calculated requirements with the available inventory,
• preparing purchase orders for materials.
mrpmrp
Material Requirement Planning SystemsMRP – an example (step 1)
The independent demand for product „A” is 100 units.
Get
Independent
Demand
The manufacture rules:
•Single manufacture order for each
item can not be smaller then 5 units.
•Each item can be manufactured in the
package of 5 units.
The purchase rules:
•Single purchase order for each item
can not be smaller then 20 units.
•Each item can be purchased in the
package of 10 units.
Material Requirement Planning SystemsMRP – an example (step 2)
The product „A” structure (BOM):
Get Product
Structure
Material Requirement Planning SystemsMRP – an example (step 3)
The gross requirements:
bold – materials
italic –sub-assembly
Calculate
gross
requirements
Material Requirement Planning SystemsMRP – an example (step 4)
The inventory balance:
Get Inventory
Balance
Material Requirement Planning SystemsMRP – an example (step 5a & 6a)
Calculations:
Calculate net
requirements
Material Requirement Planning SystemsMRP – an example (step 5b & 6b)
Calculations:
Calculate net
requirements
Material Requirement Planning SystemsMRP – an example (step 5c & 6c)
Calculations:
Calculate net
requirements
Material Requirement Planning SystemsMRP – an example (step 5d & 6d)
Calculations:
Calculate net
requirements
Material Requirement Planning SystemsMRP – an example (step 8)
Updated inventory balance:
Update
Inventory
Balance
Material Requirement Planning SystemsMRP – an example (step 9)
Production order:
Generate
Orders
Purchase order:
Material Requirement Planning SystemsMRP – Summary (1)
MRP allows you to deal with the right purchase quantities.
It is an important aspect of production planning because if a company purchases insufficient quantities of items used in manufacturing, it may be unable to meet contracts by the agreed date. On the other hand if the company purchases excessive quantities of items, money is wasted.
MRP provides answers for several questions:
• what items are required?
• how many items are required?
• when are they required?
Material Requirement Planning SystemsMRP – Summary (2)
Input data:
• a final product and its structure (BOM),
• an independent demand for the final product,
• inventory status and balance (net materials available for use already in stock and materials on order from suppliers).
Output data:
• a document Recommended Purchasing Schedule with information about items to be purchased,
• a document Recommended Production Schedule with information about items to be manufactured,
• reports (e.g. purchase orders, inventory balance).
Usually the outputs of MRP are recommendations only and should be reviewed by trained people.
Material Requirement Planning SystemsMRP – Summary (3)
The major problems with MRP systems:
• MRP does not take into consideration capacities - it gives results that may be
impossible to implement due to manpower, machine or supplier capacity
constraints,
• MRP cannot consider items which production is in progress,
• if a company has factories in different localizations MRP may consider inventory
available in one warehouse as available in the second one even if it is thousands of
miles away,
• MRP systems is very sensitive to the quality of input data - if there are any errors
in the inventory data or the bill of materials data then the outputted data will also
be incorrect.
Lecture 3
Resource Planning Systems:
Closed Loop Material Requirement Planning
Manufacture Resource Planning
Closed Loop MRP SystemsBasics
Closed Loop Material Requirements Planning (CL-MRP, MRP-CL) Systems
are an extension of MRP systems designed to handle the problem of
updating manpower, machine or supplier capacity.
The problem is solved by adding new subsystems:
• CRP (Capacity Requirements Planning) and MPS (Master Production
Schedule) included into a loop with mrp module,
• PUR (Purchasing),
• SFC (Shop Floor Control).
Closed Loop MRP SystemsAn Architecture
BOMBOM
MRPMRP INVINV
PURPUR
MPSMPS
CRPCRP
SFCSFC
ClosedClosedClosedClosedlooplooplooploop
Closed Loop MRP SystemsPurchasing (1)
Purchasing (PUR) subsystem provides purchasing control (for the
complete procurement process, from vendor quoting through receiving,
inspection, cost accrual and vendor payment) and tracks purchase orders
from its issue to receipts.
PURPUR
Planning RequisitionsPurchase
Orders
Blanket
Orders
Supplier
Schedules
Closed Loop MRP SystemsPurchasing (2)
Supplier Schedules – for high-volume, repetitive purchasing, MRP can
generate a schedule of requirements to be forwarded to suppliers. Such
requirements are shown as multiple quantity per item per due date
orders.
Requisitions – information for purchasing that items should be bought in
certain quantities by certain date.
PURPUR
Closed Loop MRP SystemsPurchasing (3)
Purchase Order (PO) – a formal agreement with a supplier to purchase a
specific quantity of items to be delivered at a specific time for a specific
price. A PO may reference a requisition which is deleted once it has been
fully satisfied.
Blanket Order – a long-term agreement with a supplier to purchase a
certain amount of material over a certain amount of time at given price.
When a need arises, a release is made against the blanket order to
generate a Purchase Order.
PURPUR
Closed Loop MRP SystemsShop Floor Control
Shop Floor Control (SFC) subsystem - a system used to schedule, dispatch
and track the progress of work orders through manufacturing based on
defined routings.
Basic functions of SFC module:
• input of manufacturing orders from MRP and execution,
• maintenance of work-centre and labour data,
• manufacturing order status reporting
• manufacturing order closing and reporting to MRP
SFCSFC
Closed Loop MRP SystemsMaster Production Schedule (1)
A Master Production Schedule (MPS) - a forward-looking plan for
production, staffing, inventory, that supports sales, shows what, how
much and when the organisation intends to make.
Master Production Scheduling subsystem translates a business plan into
a comprehensive manufacturing schedule that covers:
• what is to be assembled or made,
• when is planned to be assembled,
• what and when materials are required.
MPSMPS
Closed Loop MRP SystemsMaster Production Schedule (2)
MPS module supports:
• sales forecasts,
• customer orders,
• orders from dealers or distribution centres,
• inventory management,
• currently produced and expected finished product,
• rough-cut routing,
• quantities, types and due dates of required products.
MPSMPS
Closed Loop MRP SystemsCapacity Requirements Planning (1)
APICS defines Capacity Requirements Planning as the function of
establishing, measuring and adjusting limits or levels of capacity.
CRP refers to the process of determining in detail the amount of labour
and machine resources required to accomplish the tasks of production.
Capacity Requirements Planning (CRP) subsystem supports the
identification of production capacity problems.
CRPCRP
Closed Loop MRP SystemsCapacity Requirements Planning (2)
CRP provides analysis of the impact of the production orders (released and planned) on the various work centres within the plant.
Basic input data:
• the production order plan (generated from the material requirements planning module),
• current production order.
Output data:
• a time-phased report illustrating any overload or underload condition for the various work centres
CRP schedules and loads production orders using the standard operation routings and work centre definitions.
CRPCRP
Closed Loop MRP SystemsCapacity Requirements Planning – an example
CRPCRP
Time
Load
Capacity
CRPOverload – to
re-schedule
Closed Loop MRP SystemsMRP-CL – The planning process
Generate
ScheduleBEGIN
BOM
INV
Master Plan
Schedule
mrp
Regenerate
Schedule
mrp PUR
SFC
MPS
CRP
Check
production
capacity
XOR
is
overloaded
Is
sufficient
Production
Orders
Purchase
Orders
Accept
Schedule
END
Closed Loop MRP SystemsMRP-CL – An Example (3)Regenerate
Schedule
Is
sufficient
is
overloaded
Option 1:
Reducing the plan.
Option 2:
Shifting the plan.
Closed Loop MRP SystemsMRP-CL – An Example (4)Regenerate
Schedule
Is
sufficient
is
overloaded
Shifting the plan in a loop.
Can not be shifted.
MRP II SystemsBasics
Manufacturing Resource Planning (MRPII) was defined by APICS in 1989 as a method for the effective planning of all resources of a manufacturing company.
Manufacturing Resource Planning (MRPII) Systems are an extension of MRP-CL systems designed to cover MRPII method by planning production, distribution and finance in the whole organization.
MRPII systems may appear in two variants:
• minimal (MRPIIm)
• optional (MRPIIo)
MRP II SystemsMRPIIm
MRPIIm extends previous systems by 5 modules:
• Demand Management (DEM)
• Sales and Operation Planning (SOP)
• Resource Requirements Planning (RRP)
• Rough-cut Capacity Planning (RRCP)
• Performance Measurement (PMT)
MRP II SystemsAn Architecture
BOMBOM
MRPMRP INVINV
PURPUR
MPSMPS
CRPCRP
SFCSFC
DEMDEM
SOPSOP RRPRRP
RRCPRRCP
PMTPMT
MRP II SystemsDemand Management (1)
Demand management is a planning methodology used to manage
forecasted demand.
Demand Management (DEM) Subsystem functionality includes:
• forecasting,
• error tracking,
• inventory optimization,
• supply chain collaboration,
• flexible reporting.
DEMDEM
DEMDEM
MRP II SystemsDemand Management (2)
The following processes may be implemented in DEM subsystem:
• Location Data Management - supports the management of the master data required for physical locations,
• Inventory Processing – performs all of the tasks required to record inventory changes and related activities,
• Price Master Data Management - manages price-related data both for sales and procurement processes,
• Product Data Maintenance - manages all product data that describes its tangible and intangible products
• Retail Merchandise Distribution Management - connects objects related to supplying and logistical processes to distribute products to stores.
DEMDEM
MRP II SystemsDemand Management (3)
DEM subsystems are focused on:
• demand forecast accuracy improvement using internal demand planning,
• customer driven forecasts creation through robust sales and operations
processes
• sell side collaborative processes creation to manage demand within the
demand execution window
DEMDEM
MRP II SystemsForecasting Models (1)
Types of forecasting models (according to APICS):
• Baseline Methods – the percentage of a company’s demand that is derived from continuing contracts and existing customers, usually predictable,
• Time Series (Exponential Smoothing) – a technique that projects historical data patterns by looking at past forecasts and forecast errors; contains seasonal, cyclical, trend, and random components, e.g.:
– a weighted moving average forecasting technique where past observations are adjusted according to their age (the most recent data are weighted the heaviest).
– exponential smoothing,
– moving average,
– weighted moving average.
DEMDEM
MRP II SystemsForecasting Models (2)
• Trend – the general upward or downward movement of demand over
time,
• Seasonality – a cyclical pattern of demand where some periods of the
year are higher or lower than others,
• Regression Models – statistical techniques used to determine the best
mathematical expression that describes the functional relationship
between a dependent variable, such as demand, and one or more
independent variables,
• Focus Forecasting – a system that enables a user to simulate the
effectiveness.
MRP II SystemsSales and Operation Planning (1)
Sales and Operations Planning is a decision making process, to balance
demand and supply, to align volume and mix, and to integrate financial
and operating plans.
APICS defines SOP as the „function of setting the overall level of
manufacturing output (production plan) and other activities to best satisfy
the current planned levels of sales (sales plan and/or forecasts), while
meeting general business objectives of profitability, productivity,
competitive customer lead times, as expressed in the overall business
plan.”
SOPSOP
MRP II SystemsSales and Operation Planning (2)
Processes provide by Sales and Operations Planning (SOP) Subsystem:
– sales forecasting (gathering data on past sales, analysis of trends and forecast
reports),
– demand planning (validation of forecast data, pointing sources of demand,
analysis of variability, managing inventory and customer policies),
– supply planning (verification of the ability to meet demand by available
capacity, scheduling),
– reconciliation of plans (matching supply plans with financial considerations),
– SO plan implementation (finalization and implementation of the plan).
SOPSOP
RRPRRP
MRP II SystemsResource Requirements Planning (1)
Resource Requirements Planning concerns with strategic (long-range)
capacity requirements, linked directly to strategic planning.
RRP translates production priorities (monthly, quarterly etc.) from the
production plan into the amount of resources needed to execute this
plan.
Resource Requirements Planning (RRP) subsystem is used for a long
range capacity planning and checking whether aggregate resources (e.g.
gross labour hours, machine hours) are capable of satisfying the aggregate
production plan.
RRPRRP
MRP II SystemsResource Requirements Planning (2)
The functions of RRP subsystem:
• identification of the critical resources,
• obtaining planned production data,
• identification of product structures,
• determination of the bill of resources,
• calculation of the total resource requirements,
• evaluation of resource requirements against available resources,
• identification of shortfalls,
• validation of production plan by using the resource plan.
MRP II SystemsRough-cut Capacity Planning
Rough-cut Capacity Planning is a process of converting the production plan and/or the master production schedule into capacity needs for key resources (e.g. manpower, machinery, warehouse space, vendors’capabilities).
Rough Cut Capacity Planning allows production plans and master production schedules (and changes thereto) to be checked and adjusted for reality.
Rough-cut Capacity Planning (RCCP) subsystem is used for a intermediate-range capacity planning and supports RRP subsystem in checking the feasibility of the master production schedule.
RRCPRRCP
RRCPRRCP
MRP II SystemsRough-cut Capacity Planning - Limitations
1. RRCP does not calculate capacity requirements by work centres.
2. RRCP does not take into account work in progress, completed parts and
assemblies (that makes short-term results incredible).
3. RRCP assumes lot-for-lot (LFL) ordering in the calculation of resource
requirements.
4. RRCP bases on representative products for an entire product family
(but final products may vary and incoming orders may not exactly fit
the predicted mix).
5. RRCP considers only key or critical resources.
MRP II SystemsPerformance Measurement
Performance measurement is the continuous process whereby an organization uses the parameters and statistical evidence to determine progress toward specific defined organizational objectives.
– providing ongoing control of the MRP II system
efficiency. That is associated with formulation of goals to be achieved and checking
whether these have been achieved
Performance measurement (PMT) subsystems support:
• establishing goals and targets,
• establishing accountability,
• tracking results by working with information provided by measures over time,
• diagnosing outcomes,
• performance reporting.
PMTPMT
MRP II SystemsMRPIIo
MRPIIo version adds:
• Business Planning (BP)
• Simulation (SYM)
• Tooling Planning and Control (TP&C)
• Scheduled Receipts Subsystem (SRS)
• Input/Output Control (I/OC)
• Financial Planning Interface (FPI)
• Distribution Requirements Planning (DRP)
MRP II SystemsAn Architecture of MRPIIo systems
BOMBOM
MRPMRP INVINV
PURPUR
MPSMPS
CRPCRP
SFCSFC
DEMDEM
SOPSOPRRPRRP
RRCPRRCP
PMTPMTI/OCI/OC
SRSSRS
FPIFPI
DRPDRP
TP&CTP&C
BPBPSYMSYM
MRP II SystemsBusiness Planning
Business planning is the process of creating a business plan, which
identifies the organizational, strategic, and financial tactical goals of the
business.
The business plan is an input to the S&OP process and includes:
• long-range revenue, cost, and profit objectives
• long-range strategies and budgets,
• a projected balance sheet
• a cash flow statement.
BPBP
MRP II SystemsBusiness Planning
Business Planning (BP) subsystem supports the creation of a strategic
plan of organization’s activities.
BP is the top-level module in MRPII systems:
BPBP
Source: APICS
MRP II SystemsSimulation
Simulation is a method where systems are modelled using a specific computer program designed to mimic real systems.
Simulations can be run before a real system becomes operational to verify its design, see how the system reacts to changes in environment or in operating rules, and evaluate the system’s response to changes in its structure.
Simulation (SYM) subsystem allows you to evaluate, using simulation methods, how changes of components would affect the organization (e.g. material requirements, production capacity, financial plans).
SYMSYM
MRP II SystemsTooling Planning and Control
Tooling Planning and Control (TP&C) subsystem supports the control of
access to some tools to ensure that the production plan will be
performed.
TP&CTP&C
MRP II SystemsScheduled Receipts Subsystem
Scheduled Receipts Subsystem (SRS) allows you to control the receipt of
supplied elements and manufactured products.
Examples of reports generated from SRS:
• Component Availability Check,
• Scheduled Receipts Status Report.
SRSSRS
MRP II SystemsInput/Output Control (1)
Input/Output Control is a technique for capacity control that monitors
planned and actual inputs and outputs of a work centre.
Input/Output Control (I/OC) subsystem allows you to control production
capacities. It can be used to control queues at the workplace level, as well
as input and output levels on each workplace.
I/OCI/OC
MRP II SystemsInput/Output Control (2)
The levels of managing capacity are:
• resource planning (SOP),
• rough-cut capacity planning (RCCP),
• capacity requirements planning (CRP),
• input/output control (I/O).
At each level capacity is established, measured, monitored, and adjusted
(e.g. hiring, subcontracting, accepting stockouts) to execute operation
schedules and meet the needs. If needs are not met capacity or load must
be updated.
I/OCI/OC
MRP II SystemsFinancial Planning Interface
Financial Planning Interface (FPI) subsystem enables communication
with financial modules and gathering data from them. It provides data
processing and data transmission to everyone responsible for financial
planning.
Examples of reports generated from FPI:
• Inventory Valuations,
• Cash Flow Projections.
FPIFPI
MRP II SystemsDistribution Requirements Planning
Distribution Requirements Planning determines the need to replenish
inventory at branch warehouses.
Distribution inventories, including finished goods and spare parts, involve
items that customers might order. These inventories are either
warehoused or are in transit to customers.
An xxample of reports generated from DRP:
• Transportation Planning Report.
DRPDRP
MRP II SystemsBenefits
Successfully implemented MRP II systems can improve organization’s
efficiency by:
• better control of inventories,
• accurate scheduling,
• established relationships with suppliers,
• better design control,
• better product quality and quality control,
• reducing working capital for inventory,
• better cash flow through quicker deliveries,
• accurate inventory records.
Enterprise Resource Planning SystemsEvolution of Resource Planning Systems in
1990sMajor trends influenced resource planning systems in 1990s:
1990 – 1995:
-Reengineering (BPR)
-Cost Reduction
-Process streamlining
-Logistics and Production
cantered management
1995 – 1999:
-Additional modules
-EDI based solutions
-Customer Relationship
cantered management
1999-2000:
-Year2K problem
-Euro transition
Enterprise Resource Planning SystemsFrom MRPII to ERP (1)
The hardware and software of the 1980s was not advanced enough to
support more then manufacturing resource planning. Moreover cost of
such solutions was prohibitive for most companies.
In the early 1990s MRPII systems began to be extended by additional
modules, e.g. finance (general ledger, accounts receivable, account
payable, multiple currency) and human resource management.
Such systems were called MRPII+ (Advanced Manufacture Resource
Planning) or MRPIII (Money Resource Planning).
Enterprise Resource Planning SystemsFrom MRPII to ERP (2)
In 1996 Baan introduced Dynamic Enterprise Modelling (DEM) approach
as a way for implementing its resource planning software.
DEM was based on Petri net technique and was expected to improve
implementation process and flexibility of Baan’s solutions.
The idea of DEM was used by SAP as well, but did not become a common
standard.
Nevertheless some features of DEM can be seen in today’s systems (e.g.
based on Service Oriented Architecture).
Enterprise Resource Planning SystemsBasics (1)
Enterprise Resource Planning (ERP) system is an integrated computer-
based system, that extends MRPII solutions.
The idea of Enterprise resource planning was presented by Gartner Group
in 1990 (L. Wylie, „A Vision of Next Generation MRP II”, Scenario S-300-
339, Gartner Group, April 12, 1990) as a future of resource planning
systems.
Enterprise Resource Planning SystemsBasics (2)
ERP are used to manage internal and external resources in the
organization (manufacture resource planning, financial resources, tangible
assets, human resources) and to support managers with manufacturing,
supply chain management, financials, analytical reports (e.g. controlling)
etc.
The market of ERP systems exploded in the late 1990s as companies faced
the Y2K problem in their systems. Many of them took the opportunity to
replace older solutions with ERP systems.
Enterprise Resource Planning SystemsFeatures
ERP systems are characterized by:
• full integration inside organization and real time processing,
• connections with external systems using EDI(*),
• accessing one database (by every subsystem) to prevent redundant
data and multiple data definitions,
• easy access to any information in the system according to user
privileges,
• similar look and business logic in everyone subsystem.
Enterprise Resource Planning SystemsElectronic Data Interchange
Electronic data interchange (EDI) - the structured transmission of data
between organizations by electronic way.
EDI is used to transfer electronic documents or business data from one
(business) partner to another without human intervention.
Enterprise Resource Planning SystemsElectronic Data Interchange (1)
First EDI standards appeared in 1980s but began to be widely used in
1990s.
The standards prescribe the formats, character sets, and data elements
used in the exchange of business documents and forms
EDI standards states pieces of information (mandatory and optional)
and structure of particular documents.
EDI documents usually contain the same pieces of information that are
normally found in traditional (paper) documents used for the same
functions.
Enterprise Resource Planning SystemsElectronic Data Interchange (2)
Examples of EDI based documents that may be used for a
communication between two companies:
• Purchase Orders,
• Invoices,
• Shipping Notices,
• Export / Import Notices,
• Carrier to carrier waybills,
• Funds transfer,
• Design specifications,
• Health insurance claims.
Enterprise Resource Planning SystemsElectronic Data Interchange (3)
Examples of EDI standards:
• UN/EDIFACT (recommended by United Nations) - international
standard used outside of North America,
• EDIFICE - EDIFACT EDI standard subset for high tech and electronics
industries in Europe,
• ANSI ASC X12 (X12) – used in North America,
• EIAJ – used in Japan,
• TRADACOMS – used in the UK retail industry,
• ODETTE - used within the European automotive industry.
Enterprise Resource Planning SystemsElectronic Data Interchange (4)
Key benefits of EDI:
• provides speed (data transfer takes seconds instead of days,…),
• improves accuracy (if transmission is not successful users can invoke re-
transmission immediately,…),
• reduces costs (elimination of human handling, costs of paper, mailing;
reduction of inventory,…),
• improves operational efficiency (better relationship with trading
partners, improved planning and processing, improved cash-flow,…)
Enterprise Resource Planning SystemsAdvantages (1)
• ERP covers all functional areas like manufacturing, selling and distribution, payables receivables, inventory, accounts, human resources, purchases etc.
• ERP through the functional integration ensures proper communication, productivity and efficiency,
• ERP supports entire design process (from the project to after-sales service),
• ERP delivers data for accurate forecasting,
• ERP provides:
– inside order tracking, from acceptance through fulfilment,
– outside order tracking, from purchase orders, through inventory receipts to costing,
– the revenue cycle, from invoice through cash receipt,
– the common accounting for all tasks in the organization,
– revenue, cost and profit tracking.
Enterprise Resource Planning SystemsAdvantages (2)
• ERP integrates information processes in the whole organization (instead of many software applications that cannot communicate or interface effectively with one another),
• ERP centralizes the organization’s database and:
– permits control of all business processes even if they cross functional boundaries,
– provides higher security (against internal and external threats),
– eliminates the data synchronization between multiple systems,
– eliminates data redundancy and inconsistency,
– provides complete view of the enterprise (without „islands of information”),
– provides real time information, anytime and anywhere in the organization,
– reduces the risk of loss of data by consolidated backup.
Enterprise Resource Planning SystemsDisadvantages
• ERP has limited possibility of customization (however vendors provide special solutions for some industries),
• ERP forces change of business processes to fit „best practices” prescribed inside the system (even if it leads to a loss of competitive advantage),
• ERP is inflexible and difficult to adapt to the specific business process and workflows,
• ERP can be very expensive,
• ERP provides very high switching costs,
• ERP needs accurate data to correct processing,
• ERP does not support effectively interoperations between organization and its business partners,
• implementation of ERP takes a long time – business environment may change much quicker.
ERP marketIntroduction
According to Gartner, the overall ERP software market (including large and midmarket companies) value was $23.8 billion in total software revenue for 2008.
Gartner predicts growth to approximately $24.5 billion in 2009.
In 2007 market was shared by:
– SAP (28%),
– Oracle (14%),
– Sage (7%),
– Infor (6%),
– Microsoft (4%),
– others (41%).
ERP marketProducts by TOP12 vendors – commercial (1)
1. SAP:• SAP Business Suite
• SAP Business ByDesign
• SAP Business One
• SAP Business All-in-One
• mySAP
2. Oracle Applications:• JD Edwards EnterpriseOne
• JD Edwards World
• Oracle e-Business Suite
• PeopleSoft3.
3. Infor Global Solutions:• ERP Adage (aka Adage)
• ERP LN (aka Baan)
• ERP LX (aka BPCS)
• ERP SL (aka SyteLine)
• ERP Swan (aka Swan)
• ERP SX.Enterprise (aka SX.Enterprise)
• ERP VE (aka Visual Enterprise)
• ERP XA (aka MAPICS)
ERP marketProducts by TOP12 vendors – commercial (2)
4. The Sage Group:
• MAS 90, MAS 200 and MAS 500
• SAGE ACCPPAC
• SAGE Pro ERP
• SAGE ERP X3
• Accpac
5. Microsoft:
• Microsoft Dynamics AX (formerly Axapta)
• Microsoft Dynamics GP (formerly Great Plains)
• Microsoft Dynamics NAV (formerly Navision)
• Microsoft Dynamics SL (formerly Solomon)
6. Unit 4 Agresso:
• Agresso Business World
ERP marketProducts by TOP12 vendors – commercial (3)
7. CDC Software:
• Integrated Solutions Limited
• Ross Systems (formerly from Ross Systems Inc.)
8. Lawson Software:
• Lawson M3 (earlier * Movex from Intentia)
• Lawson S3
9. Epicor:
• Epicor 9 (replaced Epicor Vantage, Epicor Vista, Epicor Scala and parts of Epicor Enterprise)
10. Industrial and Financial Systems (IFS):
• IFS Applications
11. Comarch:
• Comarch Altum
12. QAD:
• QAD Enterprise Applications (formerly MFG/Pro)
ERP marketProducts – open source
• Adempiere (Java)
• BlueErp (PHP, MySQL, PostGreSQL)
• Compiere (Java)
• Dolibarr (PHP, MySQL, PostgreSQL)
• Fedena (Ruby Apache)
• GNU Enterprise (PHP/Python)
• JFire (Java)
• Kuali Foundation (Java)
• LedgerSMB (Perl GPL)
• OFBiz (Apache, Java)
• Openbravo (Java)
• OpenERP (Python, PostgreSQL), formerly Tiny ERP
• Opentaps (Java)
• Postbooks (C++, JavaScript, PostgreSQL)
• SQL-Ledger (Perl, PostgreSQL)
• Tryton (Python)
• WebERP (PHP, MySQL)
ERP marketAn example of midmarket analysis
Midmarket - companies or divisions of enterprises (in the example -
product-centric) with between 100 and 999 employees, and with annual
revenue between $50 million and $1 billion.
Three (Sage, Infor, Microsoft) of the top vendors are focused on the
midmarket. SAP and Oracle offer for the midmarket some of their ERP
products (SAP Business All-in-One and Oracle JD Edwards).
Significant market power has several of midmarket-focused vendors
(e.g. Epicor, IFS, Lawson, QAD, Exact Software) that are specifically
focused on selected regions or industries.
ERP marketMidmarket ERP - trends
The past few years have seen many changes in the midmarket ERP resulting
from:
– verticalization and focusing on the specific functionality for selected
industries,
– modernization using modern architecture (e.g. SOA - Service Oriented
Architecture) and transformation into model-driven applications with
embedded analytics, shifted from monolithic, inflexible products toward
sets of services that can be flexibly composed into easy-to-adapt
applications,
– globalization, that forces midmarket companies to exist as global
enterprises ,
– significant consolidation in the market (numerous acquisitions of ERP
vendors).
ERP marketGartner’s Magic Quadrant – ERP for midmarket
The Gartner Magic Quadrant is a research tool developed by Gartner Inc.
that aims to provide a qualitative analysis into a market and its direction,
maturity and participants, thus possibly enabling a company to be a
stronger competitor for that market.
– Leaders - larger industry developed businesses with vision and potential for
expansion,
– Challengers - larger, settled businesses with minimal future plans for that
industry,
– Visionaries - smaller companies that are unloading their planned potential,
– Niche players - new additions to the Magic Quadrant, or market fledglings.
ERP marketGartner’s Magic Quadrant – conclusion (1)
Only Microsoft Dynamics AX was qualified as a Leader in the market in
2009.
Through integration with other Microsoft products Microsoft Dynamics AX
gives low TCO (Total Cost of Ownership) but combats the challenges of
global implementations.
Final users are dependent on both the implementation partner and
Microsoft for future support.
ERP marketGartner’s Magic Quadrant – conclusion (2)
SAP Business All-in-One and Epicor Vantage were rated as Visionaries.
SAP Business All-in-One is one of the most advanced and complete solutions. It has the fast-start program that reduces the time and effort needed for the early phases of an implementation. On the other hand -complexity and high cost are disadvantages of this product.
Epicor Vantage was rated as the most visionary and complete application in the market. Nevertheless Epicor is a small vendor and its software is not as functionally robust as other products.
ERP marketGartner’s Magic Quadrant – conclusion (3)
Four systems were classified as Challengers.
They are broad and mature ERP solutions with strong international
presence however without real strategy for major modernizing their
applications.
Challengers have stable worldwide structures with a base of satisfied
customers.
According to Gartner, even if Challengers’ vendors was acquired, their
systems should not disappear and their customer would be supported.
ERP marketGartner’s Magic Quadrant – conclusion (4)
Six systems were stated as Niche Players.
Applications fell into this group because:
1. they offer functionally adequate product but they lack the full depth or
robustness expected by the most advanced users. Vendors usually have
limited international experience and the smaller base of customer
references.
2. they offer solutions designed for large enterprises and their cost,
complexity, scalability and scope extend midmarket users’ capabilities
and requirements.
Exterprise Resource Planning SystemsBasics (1)
The major trend that influenced development of Resource Planning
systems in 2000s was growing Internet.
Moreover disadvantages of ERP systems forced vendors and their
customers to look for a new chances for business efficiency
improvement:
– since ERP already offers complete integration inside the company then the
only way to improve business is collaboration – stronger connection with
business partners,
– since ERP is inflexible then the easy-to-compose solutions are desired.
Exterprise Resource Planning SystemsBasics (2)
The next generation of ERP systems is described by several acronyms,
e.g.:
– ERP II (Exterprise Resource Planning),
– EERP (Extended ERP),
– eERP (electronic ERP),
– iERP (internet ERP),
– @ERP (at ERP),
– EAS (Enterprise Application Suite),
– ERRP (Enterprise Resource and Relationship Processing).
Exterprise Resource Planning SystemsFrom ERP to ERPII
ERP system is enterprise-centric and focused on internal resource optimization and transactional processing. Its successor – ExterpriseResource Planning (ERP II) system - moves beyond enterprise boundaries through collaboration, SOA, data exchange and interaction methods.
Deployment strategies of ERP II systems base on information that is exchanged between two or more businesses over the Internet.
Such exchange of information (electronically via the Internet) is called collaborative commerce.
Exterprise Resource Planning SystemsERPII Definition Framework
Manufacturing, sales and
distribution, finance processesFUNCTION
PROCESS
ARCHITECTURE
DOMAIN
ROLE
DATA
ERP ERP II
Enterprise optimalization
Manufacturing and distribution
Internal, hidden
Web-aware, closed, monolithic
Internally generated and
consumed
Value chain participation/
c-commerce enablement
All sectors/segments
Cross-industry, industry sector and
specific industry processes
Externally connected
Web-based, open, componentized
Internally and externally published
and subsribed
Source: Gartner Group
Exterprise Resource Planning SystemsERPII structure
SCM – Supply Chain Management
APS – Advanced Planning and Scheduling
SRM – Supplier Relationship Management
KM – Knowledge Management
WF – Workflow Management
BI – Business Intelligence
MES – Manufacturing Execution
PRM – Partner Relationship Management
CRM – Customer Relationship Management
Exterprise Resource Planning SystemsE-business
Electronic business (e-business) - the application of information and
communication technologies (ICT) in the business activities. Electronic
business enables the external activities and relationships with
individuals, groups and other businesses to use ICT.
E-business refers to a strategic focus on the functions that let electronic capabilities
to be used.
A subset of e-business is e-commerce that seeks an additional revenue using the
Internet and builds relationships with customer through electronic media.
Exterprise Resource Planning SystemsE-business - categories
E-business activities may be classified into several categories according
to the set of business partners (classification by provider/consumer):
– business-to-business (B2B),
– business-to-consumer (B2C),
– business-to-employee (B2E),
– business-to-government (B2G),
– government-to-business (G2B),
– government-to-government (G2G),
– government-to-citizen (G2C),
– consumer-to-consumer (C2C),
– consumer-to-business (C2B).
Exterprise Resource Planning SystemsC-commerce
Collaborative Commerce (also referred as c-commerce) is a strategy
that electronically permits business interactions among an enterprise’s
internal personnel, business partners and customers.
They use together common data, available in a shared environment, to
support products throughout their lifecycle (since idea until utilization),
working separately as a virtual enterprise.
Exterprise Resource Planning SystemsSupply Chain Management
Supply Chain Management (SCM) - the management of a network of companies involved in the provision of product and service packages required by end customers.
Supply Chain Management covers product lifecycle from point of origin to point of consumption (movement and storage of materials, work-in-process inventory and finished goods).
According to APICS, SCM means the „design, planning, execution, control, and monitoring of supply chain activities with the objective of creating net value, building a competitive infrastructure, leveraging worldwide logistics, and monitoring of supply chain activities , and measuring performance globally.”
Exterprise Resource Planning SystemsAdvanced Planning & Scheduling
Advanced Planning & Scheduling (APS) - a manufacturing management process that optimally allocates materials and production capacity to meet demand.
APS is used in environments where simple planning methods are not sufficient.
APS simultaneously plans and schedules production based on available materials, labour and manufacturing capacity.
Traditional solutions use a simple stepwise procedure to allocate material and production capacity and cannot flexibly adapt to changes in demand, resource capacity or material availability. All resources are planned separately, and some of them do not consider limited material availability or capacity constraints.
Exterprise Resource Planning SystemsSupplier Relationship Management
Supplier relationship management (SRM) – a strategy of collaborative working with key suppliers to maximise the value of those relationships.
Sample capabilities of SRM systems include:
– integration of supplier product data,
– supplier collaboration (purchasing, engineering, quality, manufacturing),
– request for information, proposal or quotation management,
– internet negotiation management,
– supply chain management and scorecards,
– spend analysis and management.
Exterprise Resource Planning SystemsKnowledge Management
Knowledge Management (KM) - strategies and practices used to identify, create, represent, distribute organization’s knowledge (insights and experiences).
KM efforts can help individuals and groups to share valuable organizational insights, to reduce redundant work and training time for new employees, to retain intellectual capital as employees turnover in an organization, and to adapt flexibly to changing environments and markets.
Exterprise Resource Planning SystemsKnowledge Management
Knowledge Management focuses on:
• performance improvement,
• gaining competitive advantage,
• innovations,
• sharing of lessons learned,
• integration and continuous improvement of the organization.
Exterprise Resource Planning SystemsWorkflow Management
A workflow management (WF) system manages and defines a series of
tasks within an organisation to obtain final outcomes.
WF systems allow you to:
– define different workflows for different types of jobs or processes,
– automate redundant tasks and ensure that incomplete tasks are followed
up,
– control automated processes in addition to replacing paper work order
transfers.
Exterprise Resource Planning SystemsBusiness Intelligence
Business Intelligence (BI) - computer-based techniques used to spot,
dig-out, and analyze business data (e.g. sales revenue by products
and/or departments or associated costs and incomes) to support
business decision-making process.
BI technologies use historical, current, and predictive data. They provide
business reporting, online analytical processing (OLAP), data mining, business
performance management, predictive analytics.
Exterprise Resource Planning SystemsManufacturing Execution Systems
Manufacturing Execution Systems (MES) – a computer-based layers
between the ERP system and plant floor control systems or devices
(e.g. PLCs) that control individual machines or production lines.
A Programmable Logic Controller (PLC) - a digital computer used for
automation of electromechanical processes (e.g. to control of machinery on
factory assembly lines)
ANSI/ISA-95 - an international standard for developing an automated
interface between enterprise and control systems
Exterprise Resource Planning SystemsPartner Relationship Management
Partner Relationship Management (PRM) - a strategy that helps a
vendor to manage partner relationships better through the
introduction of reliable systems, processes and procedures for
interacting with them.
An approach to PRM includes a modification of business processes based on
the needs of partners and their customers by employee training and adoption
of relevant IT systems.
PRM strategy and associated processes and systems need to be integrated end-
to-end across marketing, sales and service.
Exterprise Resource Planning SystemsCustomer Relationship Management
Customer Relationship Management (CRM) - a strategy for managing and improving interactions with customers, clients and sales prospects.
CRM involves using IT to organize, automate, and synchronize sales activities, marketing, customer service, and technical support.
CRM systems support the relationship between a business and customers by:
– new customers acquiring through contact management, direct marketing and selling,
– enhancing by excellent service from a team of trained and skilled sales and service specialists, which offers customers the high level services,
– retaining by identifying and rewarding loyal customers and further developing targeted marketing and relationship marketing initiatives.
Exterprise Resource Planning SystemsFuture of the ERPII
A new challenge for resource planning systems - ERP III – integrates
(through collaboration, direct contact, social networks, and various
data streams within and outside of the enterprise) marketplace fans
and critics.
New, better products or services are created, produced and distributed
as a result of constructive dialog and exchange of information between
customers and vendors.
Implementation of ERP systemsThe decision to implement a system
The decision to implement management information system should
rely on company’s real business needs. Such decision should consider
every one important aspect, including organizational and financial
performance.
If a decision is taken then a coordinating team should be appointed.
The coordinating team is responsible for preparing the company to the
implementation and for the choice of a system and its vendor.
Implementation of ERP systemsPre evaluation screening
Once the company has decided to go for the ERP system, the analysis of
the organization functional and non-functional needs must start. A
team of experts with knowledge in the company’s business areas
should prepare a „snapshot” of the organization and select the most
important processes and fields to performance improvement.
Such analysis allows you to point implementation goals and ways to
measure them.
Implementation of ERP systemsPre evaluation screening – implementation goals (1)
Implementation goals result from:
• strategic and current business objectives,
• current and foreseeable conditions of company operation.
Implementation goals may have a hierarchical structure. The bottom-level goals should be sized and specified numerically to enable the organization to monitor all implementation activities.
Proper goals specification allows you to:
• select hardware and software,
• manage implementation process,
• evaluate implementation results.
Implementation of ERP systemsPre evaluation screening – implementation goals (2)
Examples of implementation goals:
• Improving the effectiveness of management– Shortening the time of production runs by xx %,
– Improving utilization of capacity by xx %,
– Improving the speed of response to competitive actions by yy hours,
– Improving information exchange with customers and suppliers by xx %,
– Improving the quality of products and services by xx %,
• Improving productivity and profitability– Reducing inventory xx %,
– Reducing the work in progress xx %,
– Reduced supply costs xx %,
– Speeding up the circulation of capital xx %.
Implementation of ERP systemsPackages evaluation
On the market there are hundreds of packages that might be implemented in the organization. It is important to eliminate those of them that are not suitable for the business process and select several packages to detailed analysis.
To evaluate packages a set of organization’s requirements (selection criteria) must be generated . They should be described and sized. Usually such requirements have weights that let their importance to be determined.
The system that best meets the requirements should be selected and implemented.
Implementation of ERP systemsPackages evaluation – the process (1)
The process of package selection is considered as one of the most important stages. The system that one selects will decide the success or failure of the project. In case of huge investments it is not easy to switch between different packages, so usually there is no place for an error.
Common mistakes in the process include:
– incomplete requirements,
– reliance on vendor demos,
– over-emphasis on system cost,
– selection bias.
Implementation of ERP systemsPackages evaluation – the process (2)
The evaluation and selection process includes:
1. identification of packages to be evaluated („long list”),
2. development of selection criteria (high level differentiating factors),
3. create a Request for Proposal (RFP),
4. distribute RFP to the software vendors,
5. first evaluation of packages (rank vendor responses),
6. selection of the several packages („short list”) to final evaluation,
7. meetings with consultants (vendor demonstrations),
8. reference (site) visits,
9. final evaluation (including price and terms of service),
10. selection recommendation to executives.
Implementation of ERP systemsPackages evaluation – selection criteria (1)
Selection criteria may be divided into several groups:
• database & networks,
• hardware & software,
• implementation,
• functional factors,
• non-functional factors,
• support.
Implementation of ERP systemsPackages evaluation – selection criteria (2)
Database & networks – the example of questions:
• How many user licenses are required?
• How user licences are counted (per named or open user)?
• Is the system designed to work with different relational database management systems?
• What is the maximum time it takes to restore the system?
• Does the package support distributed data processing?
• How many security layers have been incorporated into the software?
• What is the largest database the vendor has handled so far?
Implementation of ERP systemsPackages evaluation – selection criteria (3)
Hardware & software – the example of questions:
• What kind of hardware does the vendor offer?
• What kind of system software (commercial or open) does the vendor offer?
• How many operating systems does the software support?
• How many years of experience does the vendor have with the offered combination of hardware and software?
• Is the upgrade support (for the software and hardware) possible?
• Does the software have any interface to integrate the latest technology?
• Can be the software purchased and implemented as modules?
Implementation of ERP systemsPackages evaluation – selection criteria (4)
Implementation – the example of questions:
• Does the vendor have proven implementation plan and methodology?
• Has the vendor implemented sites in the our region?
• Has the vendor implemented an offered solution in our industry segment?
• How long did it take the vendor to implement the system and itsmodules?
• How many years of experience does the vendor have with implementation?
• Does the vendor have an implementation team with the required skills?
• How many Certifications of Excellence given by other customers doesthe vendor have?
Implementation of ERP systemsPackages evaluation – selection criteria (5)
Functional factors – the example of questions:
• Does the software meet our functional requirements?
• Will the accounting module adhere to international standards and to our country’s standards?
• Will the HR module adhere to our country’s regulations?
• Does the vendor promise any optimization in lead times?
• Does the software use a built-in business process modeller?
• What is the processing time (minimum/maximum) for MRP/MPS?
Implementation of ERP systemsPackages evaluation – selection criteria (6)
Non-functional factors – the example of questions:
• Is the user interface friendly and usable?
• Does the software handle data conversions?
• Can the vendor have any programs for importing and exporting data?
• Can the vendor give approval for adding own functionality?
• Does the vendor offer any test database for proper training?
• How high is reliability level of system’s data?
• How secure is the system?
• How flexible is the system?
Implementation of ERP systemsPackages evaluation – selection criteria (7)
Support – the example of questions:
• What kind of support will the vendor provide after implementation?
• Does the offered support include free visits of consultants?
• For how long time does the vendor offer free support?
• How much must we pay for the maintenance?
• How does vendor’s support units work (how many hours per work day / weekend day)?
• How quick will the vendor react to our problems?
• How often does the vendor offer upgrades of offered software?
Implementation of ERP systemsProject Planning
This phase allows you to design the implementation process plan,
including:
• time schedules,
• deadlines,
• milestones,
• roles,
• responsibilities.
The planning should be done by a committee of team leaders and
accepted by the top-level managers.
Implementation of ERP systemsGAP analysis
Even the best package will not cover 100% of requirements. GAP analysis allows you to identify the gaps that need to be traversed to make the company's practice included into the system.
Usually the question to answer is: Should we adjust the system to the organization or the organization to the system?
To complete this stage it is important to compare a complete model of current position of the organization („as-is”) and a model of the future vision of organization („to-be”).
The gap presents problematic issues for the company’s reengineering.
Implementation of ERP systemsProcess reengineering
Process reengineering allows you to reduce the gaps and change
organizational data and work flow.
In this phase human factors are taken into consideration.
Implementation involves changes in the number of employees and
their job responsibilities so business processes must be changed as
well.
Implementation of ERP systemsSystem customization
If the gap analysis shows that some changes are necessary in the
computer system then offered functions must be changed or added. It
is called „customization”.
Sometimes it is enough to set specific values of the pre-defined
parameters in the system.
If the system is flexible then it is easier to make customization without
changing the source code.
Implementation of ERP systemsTesting & optimization management
When the system is installed it must be verified by a pilotage start-up. In this phase a company tests the real case scenarios.
Tests include: plan, realization and analysis. Any problems should be solved and the system performance should be optimized.
Typical tests scenarios include:
• system overloading,
• multiple users logging on at the same time,
• users entering invalid data,
• finding errors in the business data flow,
• unauthorized accessing.
Implementation of ERP systemsImplementation evaluation
Finished process should be evaluated.
It is important to compare goals of the implementation and its results.
It needs performance and benefits re-measurement according to the
metrics used before in the pre-evaluation phase.
Implementation of ERP systemsContinuous working assurance
The implemented system will influence organization for many years so
it must be accurate and reliable.
It should be monitored and updated if necessary.
Implementation of ERP systemsTop management training
Who:
Training for the members of managing and middle-level management and the coordination team.
What:
General knowledge of:
– computer applications, their functionalities and the effectiveness,
– the organization of the implementation process,
– general knowledge about processes implemented in the package.
How:
Theoretical lectures and seminars.
Implementation of ERP systemsProject management team training
Who:
Training for the members of the middle and lower level management and the project management team.
What:
General knowledge of:
– project management methodologies and tools,
– project organization,
– basic functionality of the package,
– basic parameterization and customization of the system.
How:
Theoretical seminars, practical case studies and project management tools usage.
Implementation of ERP systemsImplementation teams training
Who:
Training for members of lower-level management, members of the implementation groups and key users of the system.
What:
Knowledge of:
– project organization in the implementation groups,
– general processes flow in the selected areas,
– detailed parameterization and customization of the system.
How:
Some theoretical seminars and practical usage of the system’s main functionality.
Implementation of ERP systemsFinal users training
Who:
Training for the members of the implementation groups, key users and
the final users of the system.
What:
Knowledge of:
– system functionality in details.
How:
Detailed practical usage of the system’s main functionality.
Implementation of ERP systemsSystem administrators training
Who:
Training for the employees of IT department with appropriate practice.
What:
Knowledge of:
– database management,
– system administration,
– user management,
– backup management.
How:
Practical database management and system maintenance.
Implementation of ERP systemsContinuous training
Who:
All systems users.
What:
Knowledge of:
– new functionality,
– changed processes.
Repetition of the knowledge trained before.
How:
Practical knowledge of system usage.
Implementation of ERP systemsImplementation strategies
The most common ERP implementation strategies are:
Big bang – all users move to the new system together, on a
given date; the implementation of the system happens in a
single instance,
Parallel adoption – new and old systems work at the same time
until users learn how to use the new system,
Phased rollout – users move to the new systems in a series of
steps; module by module or business unit by business unit.
Implementation of ERP systemsImplementation strategies – Big bang (1)
Characteristics of the approach:
• implementation as a single event,
• installation of the modules across the entire organization at once,
• old system is turned off after a new system launching,
• high risk of the failure,
• quick implementation,
• relatively cheap implementation.
Implementation of ERP systemsImplementation strategies – Big bang (2)
Pro:
• short time of the implementation,
• implementation problems are condensed,
• employees are trained only on the new systems, not for the changeover time,
• implementation’s influence on the organization work is lower,
• costs are relatively low,
• implementation ends on the single, well-known date.
Contra:
• details may be missed in the rush of change,
• employees are trained only before start-up, they have less time to learn,
• people may be overloaded by the necessary work,
• problems with one module impact on the rest of the system,
• testing is limited.
Implementation of ERP systemsImplementation strategies – Phased rollout (1)
Characteristics of the approach:
• implementation as a single event,
• installation of the modules across the entire organization one by one,
• old system is not turned off after a new system launching – both of them are used by employees,
• low risk of the failure,
• employees have doubled work,
• high costs of the implementation.
Implementation of ERP systemsImplementation strategies – Phased rollout (2)
Pro:
• low risk,
• easy to roll-back,
• employees must be trained for the changeover time,
• users may learn the new system while performing regular activities,
• testing may be performed on the real data.
Contra:
• higher cost of the implementation,
• the most expensive implementation method,
• people may be overloaded by the necessary, doubled work,
• the date of the implementation’s end is not known and may change.
Implementation of ERP systemsImplementation strategies – Parallel adoption (1)
Characteristics of the approach:
• implementation as a sequence of small events,
• installation of modules across the entire organization one by one,
• experience gained in one iteration may be used in the next ones,
• old system is turned off after a new system launching,
• medium failure,
• the slowest implementation,
• medium cost of the implementation.
Implementation of ERP systemsImplementation strategies – Parallel adoption (2)
Pro:
• experience is gained during step-by-step implementation,
• time for adjustment,
• more time for employees to adapt to the new system,
• implementation cost is incurred in the long term,
• costs are no too high,
• implementation may be divided into parts with known end dates.
Contra:
• involves continuous change over a long period of time,
• extremely long duration of the project,
• people may work slow without the pressure of time,
• testing is necessary for the each module and for their integration.
Implementation of ERP systemsImplementation methodologies
Almost all vendors have their own implementation methodologies that help to manage implementation project.
Each methodology goal is to effectively optimize resources (time, people, money), using a proven procedures and documentation to implementation a system.
Some examples of such methodologies are:
• Accelerated SAP (ASAP) by SAP,
• Oracle AIM (Applications Implementation Methodology) by Oracle,
• Q-Advantage by QAD.
Implementation of ERP systemsImplementation methodologies – example (ASAP)
ASAP methodology focuses on tools and training. It includes five phases in the process oriented road map:
1. Project Preparation
2. Business Blueprint
3. Realization
4. Final Preparation
5. Go-Live and support
Implementation of ERP systemsImplementation methodologies – ASAP (1st phase)
The first phase (Project Preparation) includes:
• Goal setting (defining project goals and objectives),
• Implementation strategy (setting the scope of the project and establishing the project organization),
• Implementation sequence (defining a sequence of activities in the project),
• Team (establishing a core team, project team and consultant team),
• Sign off (documenting previous steps and signing them).
Implementation of ERP systemsImplementation methodologies – ASAP (2nd phase)
The second phase (Business Blueprint) includes:
• Scope document (a document consists of questionnaire of entire business process),
• As is (actual model of business processes),
• To be (optimized model of business processes),
• Gap analysis (differences between „as is” and „to be” states),
• Sign off (documenting previous steps and signing them).
Implementation of ERP systemsImplementation methodologies – ASAP (3rd phase)
The third phase (Realization) leads to implementation of all the business process requirements based on the Business Blueprint and includes:
• Baseline (major scope),
• Final configuration (remaining scope),
• Sign off (documenting previous steps and signing them).
Implementation of ERP systemsImplementation methodologies – ASAP (4th phase)
The fourth phase (Final Preparation) includes:
• Unit testing (testing within each module),
• Integration testing (testing the integration of the modules),
• User training,
• Cut over strategy (legacy system migrates to SAP system),
• Sign off (documenting previous steps and signing them).
Implementation of ERP systemsImplementation methodologies – ASAP (5th phase)
The fifth phase (Go-Live and support) includes:
• Production support,
• Monitor system transactions,
• Optimize performance,
• Help Desk & Competency Centre.
Implementation of ERP systemsEmployee resistance to change
Resistance:
• behaviour which is intended to protect an individual from the effects of
real or imagined change (Zander),
• any conduct that serves to maintain the status quo in the face of
pressure to alter the status quo (Zaltman&Duncan),
• employee behaviour that seeks to challenge, disrupt or invert prevailing
assumptions, discourses and power relations (Folger&Skarlicki).
Implementation of ERP systemsEmployee resistance to change - reasons
Alvin Zander described six primary reasons for resistance to change:
1. the nature of the change is not clear to the people who are going to be
influenced by the change,
2. the change is not explaining and may be interpreted on many ways,
3. influenced people feel strong forces deterring them from changing,
4. the people influenced by the change have pressure put upon them to
make it, instead of explaining them the nature and the direction of the
change,
5. the change is made on personal grounds,
6. the change ignores the already established informal structure.
Implementation of ERP systemsEmployee resistance to change - factors
Typical factors that may influence employee resistance:- surprise,
- inertia,
- misunderstanding,
- emotional factors,
- lack of trust,
- fear of failure,
- personal conflicts,
- poor training,
- threat to job status,
- work group break up,
- uncertainty.
Implementation of ERP systemsEmployee resistance to change - strategies
Typical strategies to minimize the employee resistance:- education,
- participation,
- facilitation,
- negotiation,
- manipulation,
- coercion,
- discussion,
- financial benefits,
- political support.
The main software architectures
• Monolithic architecture
• Client–server architecture
• Three-tier architecture
• Service-oriented architecture
Monolithic architecture
Monolithic architecture - a single-tiered architecture where the user
interface and data access code are combined into a single program served
from a single platform.
Features of monolithic architecture:
• self contained,
• independent from other computing applications,
• application is responsible for the complex functionality nor specific tasks.
Client-server architecture
Client-server architecture - a distributed, two-tiered architecture where
tasks are divided between the providers of a resource or service (servers),
and service requesters (clients).
Features of client-server architecture:
• enables the roles and responsibilities of a computing system to be
distributed among several independent computers,
• data is stored on the servers and distributed to the clients,
• high scalability of the solution,
• client may process data or request data processing by a server.
Three-tier architecture
Three-tier architecture - a kind of client–server architecture where the user interface, business logic, computer data storage and access are independent, most often developed on separate platforms.
Tiers:
• presentation tier – the top level of the application that displays information related to services; it communicates with other tiers by standardized communications to and from browser,
• business logic (application tier) - pulled out from the presentation tier and controls an application’s functionality by performing data processing,
• data tier - consists of database servers where information is stored and retrieved.
Service oriented architecture
Service Oriented Architecture (SOA) - a kind of three-tier architecture that
provides a way for consumers of services, such as web-based applications.
SOA lets you integrate applications developed and deployed in different
implementation languages and uses multiple implementation platforms.
SOA is based on orchestration - the automated arrangement,
coordination, and management of complex services.
Service oriented architectureDefinition
According to OASIS (Organization for the Advancement of Structured
Information Standards) SOA is:
„a paradigm for organizing and utilizing distributed capabilities that may
be under the control of different ownership domains. It provides a uniform
means to offer, discover, interact with and use capabilities to produce
desired effects consistent with measurable preconditions and
expectations”.
Service oriented architectureBasic concepts – service (1)
Service – „a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description” (OASIS SOA Reference Model).
Principal concepts connected with the term „service”:
„Service Description”, „Visibility”, „Interaction”, „Real World Effect”, „Execution Context”, „Contract & Policy”.
Service oriented architectureBasic concepts – service (2)
Service Description means the information that is needed in order to use
a service; it supports interaction and visibility,
Visibility means that service should have capabilities to be able to interact
with each other’s service, including functionality, technical requirements,
policies and mechanisms for access and response,
Interaction - between service providers and consumers, the exchange of
messages and triggers that invoke actions; the result of an interaction is a
real world effect.
Service oriented architectureBasic concepts – service (3)
Real World Effect - the result of using a service - the return of information
or the change in the state of entities involved in the interaction,
Execution Context describes the set of technical and business features
that link needs and capabilities and that permit service providers and
consumers to interact,
Contract & Policy - constraint or condition on the use, deployment or
description of an owned entity as defined by any participant, while a
contract represents an agreement by two or more parties.
Service oriented architectureBasic concepts – service consumer
The service consumer uses services to fulfil needs by finding services in
the service registry and binding service provider to invoke one of them.
The service consumer may be represented by:
• a human user,
• a service.
Service oriented architectureBasic concepts – service provider
The service provider creates a service and publishes its interface and
access information to the service registry.
Service provider decides which services can be exposed, how to ensure
security and availability.
Service oriented architectureSOA principles (1)
Encapsulation – services may be consolidated for use under the SOA even not planned to be used as service-oriented,
Loose coupling – services are expected to provide a minimum relationship dependencies.
Contract – services use a communications agreement, defined collectively by one or more service-description documents.
Abstraction – services hide logic from the outside world,
Reusability – logic is divided into services that should be reused.
Service oriented architectureSOA principles (2)
Composability – atomic services can be coordinated and composed to form
composite services,
Autonomy – services have their own, encapsulated business logic,
Optimization – services may be grouped and high-quality (according to set
metrics) services are preferable to low-quality ones,
Discoverability – services can be found and accessed via available discovery
mechanisms (knowledge mining),
Relevance – functionality is delivered at a granularity that allows for a
meaningful service.
SOA Maturity ModelIntroduction
SOA Maturity Model was published in October 2005 as a product of collaboration of Sonic Software Inc., BearingPoint, Systinet and AmberPoint.
The purpose of this model was to present the adaptation of the SOA schema, which would maximize the benefits, define requirements, estimate effort, and the sequence of SOA implementation process.
The SOA MM structure follows the previous maturity models: Capability Maturity Model® (CMM) and CMM Integration (CMMI) developed by the Software Engineering Institute (SEI).
SOA Maturity ModelStructure (1)
SOA Maturity Model include five levels:
1. Initial Services,
2. Architected Services,
3. Business Services&Collaborative Services,
4. Measured Business Services,
5. Optimized Business Services.
SOA Maturity ModelLevel 1 - Initial Services (1)
Prime business benefits: new functionality
Scope: research&development experimentation, pilot projects, web site,
portal, custom integration, small number of services
Critical technology success factors: standards, legacy integration
Critical people&organizational success factors: developers learn service
development skills
Relevant standards: XML, XSLT, WSDL, SOAP, Java, .NET
SOA Maturity ModelLevel 1 - Initial Services (2)
Key goals:
• Learn SOA technology in R&D and pilot projects.
• Apply SOA technology to immediate organizational needs.
• Define initial ROI measurements for SOA projects and apply to initial projects.
Key practices:
• Create service definitions.
• Integrate SOA into project development methodology.
• Quantify costs, time and business benefits of pilot projects.
SOA Maturity ModelLevel 1 - Initial Services (3)
internet
Sales Management Portal Server
Service Interface
Sales forecasting and
tracking service
Service Interface
Client relationship
management service
Service Interface
Portal user
Portal user
Enterprise Service Bus
Service Level Management
Service
Service Interface
Services Registry
Service Interface
administrator
intranet
SOA Maturity ModelLevel 2 - Architected Services (1)
Prime business benefits: IT cost reduction and control
Scope: multiple integrated applications
Critical technology success factors: support for heterogeneity and distributed
systems, reliable messaging, mediation, easy of deployment, database
integration, versioning, internal security, performance management
Critical people&organizational success factors: architecture group provides
leadership, SOA competence centre, CIO sponsorship
Relevant standards: UDDI, WS-ReliableMessaging, WS-Policy, WS-
Addressing, WQuery, WS-Security, SAML
SOA Maturity ModelLevel 2 - Architected Services (2)
Key goals:
• Institutionalize use of SOA.
• Put in place architecture leadership for SOA.
• Prove returns from use of standards technology.
Key practices:
• Specify technology standards for SOA.
• Integrate SOA into organization-wide development process.
• Provide organization-wide SOA training and competency center.
• Use incremental integration.
SOA Maturity ModelLevel 2 - Architected Services (3)
Purchase Order Service
Service Interface
Order Management
Service
Service Interface
Funds Transfer Service
Service Interface
Enterprise Service Bus
Service Level Management
Service
Service Interface
Service Interface
administrator
intranet Exception Management
Service
Service Interface
Single Sign On
Service Interface
bank
suppliers
Agents
XML
Services & Policies
Repository
SOA Maturity ModelLevel 3a - Business Services (1)
Prime business benefits: business responsiveness – change business
processes quickly and effectively
Scope: business processes across business unit or enterprise
Critical technology success factors: reuse, easy modification, availability,
business process rules, event-driven processes, composite applications
Critical people&organizational success factors: IT partnership with business
partnership across organizations, SOA lifecycle governance, executive
commitment, event-driven design skills, business unit, manager
sponsorship
Relevant standards: WS-BPEL
SOA Maturity ModelLevel 3a - Business Services (2)
Key goals:
• Create ongoing partnership between business and technology
organizations for SOA governance.
• Support full business processes via SOA.
• Prove returns from reuse of services and responsiveness to change.
Key practices:
• Specify policies for use of SOA in creation or modification of business
processes.
• Take advantage of event-oriented and mediation functionality of SOA
technologies, especially with regards to enhancing/extending business
processes.
SOA Maturity ModelLevel 3a - Business Services (3)
Purchase Order Service
Service Interface
Internal orders service
Service Interface
Pricing and offers service
Service Interface
Enterprise Service Bus
Service Level Management
Service
Service Interface
Service Interface
administrator
intranet Exception Management
Service
Service Interface
Single Sign On
Service Interface
bank
supplier
agents
XML
Services & Policies
Repository
Inventory control service
Service Interface
Orchestration Service
Service Interface
[1] [2]
[3]
[4]
SOA Maturity ModelLevel 3a - Business Services (4) - reusability
Purchase Order Service
Service Interface
Internal orders service
Service Interface
Pricing and offers service
Service Interface
Enterprise Service Bus
Service Level Management
Service
Service Interface
Service Interface
administrator
intranet Exception Management
Service
Service Interface
Single Sign On
Service Interface
bank
suppliers
agents
XML
Services & Policies
Repository
Inventory control service
Service Interface
Orchestration Service
Service Interface
[1b] [2]
[3]
[4]
Purchase optimalization
service
Service Interface
[5]
Material Requirements
Planning (MRP) service
Service Interface
[1a]
SOA Maturity ModelLevel 3b - Collaborative Services (1)
Prime business benefits: business responsiveness – collaboration with business and trading partners
Scope: service available to external partners, cross-enterprise
Critical technology success factors: external service enablement, cross-enterprise security, translation of cross-enterprise protocols, long-running transactions
Critical people&organizational success factors: IT partnership with business partnership across organizations, SOA lifecycle governance, executive commitment, event-driven design skills, business unit, manager sponsorship (as before)
Relevant standards: RosettaNet, ebXML, WS-Trust
SOA Maturity ModelLevel 3b - Collaborative Services (2)
Key goals:
• Create ongoing partnership between business and technology organizations for SOA governance.
• Extend SOA business processes to external organizations.
• Prove returns from use of services for collaboration.
Key practices:
• Specify policies for use of SOA in collaboration with business and trading partners
• Implement cross-enterprise security.
SOA Maturity ModelLevel 3b - Collaborative Services (3)
internet internet
Purchase Order Service
Service Interface
Internal orders service
Service Interface
Pricing and offers service
Service Interface
Enterprise Service Bus
Service Level Management
Service
Service Interface
Service Interface
administrator
intranet Exception Management
Service
Service Interface
Single Sign On
Service Interface
bank
XML
Services & Policies
Repository
Inventory control service
Service Interface
Orchestration Service
Service Interface
[1b] [2]
[3]
[4]
Purchase optimalization
service
Service Interface
[5]
Material Requirements
Planning (MRP) service
Service Interface
[1a]
Service Interface
Sales quites service
Service Interface
Material shipment service
Service Interface
Collaboration service
Service Interface
Service Interface
SOA Maturity ModelLevel 4 - Measured Business Services (1)
Prime business benefits: Business transformation from reactive to real-time, meet business performance metrics
Scope: business unit or enterprise, cross-enterprise
Critical technology success factors: business activity monitoring, event stream processing, complex event processing, event-driven dashboards and alerts
Critical people&organizational success factors: on-going business process evaluation and response, CFO sponsorship
SOA Maturity ModelLevel 4 - Measured Business Services (2)
Key goals:
• Institute transformation from reactive to real-time business processes.
• Define and meet business-oriented performance metrics.
Key practices:
• Collect and analyze business process oriented real-time performance metrics.
• Implement ongoing business process evaluation and re-engineering.
SOA Maturity ModelLevel 5 - Optimized Business Services (1)
Prime business benefits: business optimization
— react and respond automatically
Scope: business unit or enterprise, cross-enterprise
Critical technology success factors: event-driven automation for optimization
Critical people&organizational success factors: continuous improvement
culture, CEO sponsorship
SOA Maturity ModelLevel 5 - Optimized Business Services (2)
Key goals:
• Provide enterprise-wide leadership for business and SOA governance.
• Prove returns from SOA-supported continuous improvement.
Key practices:
• Implement self-correcting business processes.
Recommended