Business Information Systems Adam Wasilewski , PhD ... · Transaction processing systems (TPS) - a type of system intended to automate the handling of business activities or transactions

Business Information SystemsBusiness Information Systems

Adam Adam WasilewskiWasilewski, PhD, PhD

Management Information Systems Management Information Systems

Lecture 1

Introduction to 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


Decision making

Type of

decisionOperational Tactical Strategic

Structured

Semi-structured

Unstructured



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








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








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








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








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








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








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








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.

Lecture 2

Resource Planning Systems:

Material Requirement Planning

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)

1960 1970 1980 1990 2000 2010

IC

MRP

complexity

date

MRP-CL

MRPII

ERP

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.

1960 1970 1980 1990 2000 2010

IC

MRP

complexity

date

MRP-CL

MRPII

ERP

ERPII

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


Indented explosion of item

#A

BOMBOM


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 – the planning process

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.


The product „A” structure (BOM):

Get Product

Structure


The gross requirements:

bold – materials

italic –sub-assembly

Calculate

gross

requirements


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



Updated inventory balance:

Update

Inventory

Balance


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?


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.


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


Closed Loop Material Requirement Planning

Manufacture Resource Planning

1960 1970 1980 1990 2000 2010

IC

MRP

complexity

date

MRP-CL

MRPII

ERP

ERPII

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


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


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 – I/O Model

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 (1)Generate

Schedule

The generated Master Plan Schedule:

Closed Loop MRP SystemsMRP-CL – An Example (2)

Check

production

capacity

is

overloaded

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.

1960 1970 1980 1990 2000 2010

IC

MRP

complexity

date

MRP-CL

MRPII

ERP

ERPII

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


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


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.

Lecture 4


Enterprise Resource Planning

Exterprise Resource Planning

1960 1970 1980 1990 2000 2010

IC

MRP

complexity

date

MRP-CL

MRPII

ERP

ERPII

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.


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.


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.


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 SystemsAn example of ERP system structure

Source: bluedzine.com

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)


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


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 – ERP for midmarket

(2)

Source: Gartner Group

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.


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.


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.


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.

1960 1970 1980 1990 2000 2010

IC

MRP

complexity

date

MRP-CL

MRPII

ERP

ERPII

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.

Lecture 5

ERP Implementation The Process

Implementation of ERP systems

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.


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?


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 – 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?


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?


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?


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.

Lecture 6

ERP Implementation Training

Implementation MethodologiesResistance to Change

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)


• 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)


• 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),


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),


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),


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 systemsImplementation methodologies – ASAP Roadmap

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.

Lecture 7

Service Oriented Architecture

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 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.


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 architectureRelationships in SOA

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 ModelStructure (2)

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


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.


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


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.


Purchase Order Service

Service Interface

Order Management

Service

Service Interface

Funds Transfer Service

Service Interface



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


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.



Service Interface

Internal orders service

Service Interface

Pricing and offers service

Service Interface



Service

Service Interface

Service Interface

administrator


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


Service Interface


Service Interface


Service Interface



Service

Service Interface

Service Interface

administrator


Service

Service Interface

Single Sign On

Service Interface

bank

suppliers

agents

XML

Services & Policies

Repository


Service Interface


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


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.


internet internet


Service Interface


Service Interface


Service Interface



Service

Service Interface

Service Interface

administrator


Service

Service Interface

Single Sign On

Service Interface

bank

XML

Services & Policies

Repository


Service Interface


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


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.


Me

an

ing

ful e

ve

nts

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


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.


bank

Me

an

ing

ful e

ve

nts

Documents

Business Information Systems Adam Wasilewski , PhD ... · Transaction processing systems (TPS) - a type of system intended to automate the handling of business activities or transactions