Transcript What is an Enterprise Wide Application?

Enterprise Business
Processes and Applications
(IS 6006)
Masters in Business Information Systems
6th Jan 2009
Fergal Carton
Business Information Systems
Course Objective
To understand the key processes
underlying modern organisations and
how enterprise wide systems support
these processes
Covered so far
•
•
•
•
•
•
•
•
•
•
What are business processes?
Key demand and supply processes
Integration and standardisation
Different aims of organisational functions
Key information resources shared by those functions
What are enterprise applications (ERP / CRM / SCM)?
Historical perspectives on enterprise applications
Single instance implementations and data integrity
Project management (Gap analysis, resources, …)
Reporting and data access in the enterprise
This week
•
•
•
•
•
•
Single instance ERP systems
Hardwiring processes
Impact for subsidiaries
Data integrity issues
Gap analysis (UCC example)
Scope definitions
Single instance
•
•
•
•
•
One system clock
One copy of the production data
One version of master data
One transaction engine
One database administrator
ERP is often single instance
•
•
•
•
•
Single point of data entry (PO’s, SO’s, …)
Inventory control
Opportunity to re-design processes
Single technical platform (support)
Common language, common pool of data
Sales
Production
Shipping
Collect cash
Customer information (ship-to, bill-to, install-at, …)
ERP “hardwires” processes
• Human decisions replaced by data and interfaces
– An approved sales order triggers the creation of an invoice
(running Accounts Receivable “interface”)
– A production schedule triggers the creation of work orders
– A batch release from warehouse triggers quality checks
– A component quality failure triggers purge on all inventory
– An incomplete payment triggers a debit note
– An unpaid invoice triggers a reminder letter
– …
Increased focus on data!
Single instance scenario: SIT
•
•
•
•
•
•
•
ERP database is in Boston
43 countries linked via Wide Area Network
4,500 users (# concurrent users?)
20,000 customer records (all countries)
10,000 supplier records
1,400 products in price book
10,000 shipments per quarter (for one
plant)
Impact for subsidiaries:
the good news
•
•
•
•
•
Complete conformance to HQ standards
No need to re-work local data for HQ
Little local IT support required for ERP
Real time visibility of worldwide operations
Closing the books quickly (2-5 days)
Impact for subsidiaries:
the bad news
• Gap between template process & reality
– Workarounds can be onerous
• System response time degradation
• Support structure is centralised
• Lack of transparency of transactions
– Transactions can get stuck in interface
• Inability to access data for reporting
Data integrity issues
• Forecast figures versus plan
• Buffer stocks (GSK)
• Multiple repositories of customer data
(EMC)
• Multiple repositories of product data
(GSK)
• Sales holding back on deals (EMC)
• Lack of faith in orders (EMC)
Data integrity issues eg. customers
• When creating a new customer, who has
control?
• 42 occurrences of one customer in your
database, why?
• Customers exist in ERP core database, but
also in several legacy systems. How do you
make sure they are in synch?
• Different depts. require and record different
addresses for same customer (ship-to, bill-to,
install-at, …)
SIT production planning: single
instance impact?
• Planning extremely manual (Excel based)
• By definition planning is by plant (local)
• What impact would a global single
instance system have?
– Customer benefit?
– Efficiency gain?
Gap analysis: expectation mgt
• Describe existing processes
– Document how things are currently done
– Review inputs and outputs of current process (screens, forms,
reports)
– Outline problems with current way of doing things (speed, risk of
error, …)
– What improvements are expected from system (single point of
data entry, faster reports, less manual work, …)
• How to design and communicate the proposed solution
– Review ERP documentation: collate with existing processes
– Review responses of vendors to User Requirements Spec
– Walk-through solution, highlighting differences
GAP analysis = setting the scope
• Reconciling technological necessities of the
system with business needs
• ERP systems impose their own logic
• Balancing the way you want to work with the
way the system will let you work
• 2 stage model for scope decisions
– Choice of modules (Purchasing, AP, …)
– Configuring the system to your way of working
Davenport, 1998
Other scope definitions
•
•
•
•
•
Number of modules
Number of functional units affected
Number of sites
Extent of customisation
Number of interfaces with legacy
applications
Bingi, 1999
UCC Finance – Phase 1
Purchasing
Accounts
Payable
Fixed
Assets
Cash
Budgeting and Forecasting
Reporting
General Ledger
Accounts
Receivable
Analysing Fit
•
•
•
•
Functionality grid
Break down per functional area
Down to process stage level
Ask vendors to rate fit
–
–
–
–
Not supported
Supported with mod / workaround
Supported with minor alteration
Fully supported
• Score and recommend (see diagram)
UCC Finance - modules
• General Ledger
• Accounts Payable/Creditors ledger including Tax Compliance
Reporting
• Accounts Receivable/Debtors ledger/Invoicing
• Procurement Management
• Purchase Order Processing
• Cash Book, Cash Receipts, Cash Forecasting
• Capital Project Accounting
• Fixed Asset Register and Management
• Research Accounting
• Budgeting and Forecasting
• Tax Compliance & Reporting
• Costing
• Report Writers
• System Manager
System requirements
• System requirements describe the needs and
desires of an information system
– Must-have
– Nice-to-have
• Requirements can be categorised as
– Functional (an action)
• Eg. the system should process a spending request
– Non-functional (a feature or constraint)
• Eg. budgets are confidential to the department concerned
UCC Finance requirements
• For each requirement, a rating has been
provided, as follows:
*
M Mandatory
*
I
Important;
*
D
Desirable (‘nice to have’)
Valid
Response to
Level of Fit
A
B
C
D
E
F
X
Explanation
Instructions
Standard functionality – the package meets
the requirement as stated, with no need for
custom development or effort other than
parameterisation.
Equivalent functionality - the package does
not satisfy the requirement as stated, but it
provides an alternative method that you
believe will provide the same desired result
without customisation.
Workaround - the package does not satisfy
the requirement as stated, but the same desired
result could be achieved by a workaround
(without affecting core software).
Modification required with no cost - the
requirement cannot be met by the package but
some customisation could be performed at no
additional cost.
Modification required with cost - the
requirement cannot be met by the package but
some customisation could be performed at an
additional cost.
Enhancement to be provided in a future
release
Not Supported - the requirement is not
supported by the package.
In these cases, elaborate on the answer if you
feel it is appropriate.
In these cases describe the method, and
justify your belief that it is equivalent.
In these cases the workaround must be
described.
The proposed modification should be
described with an estimate given in terms of
man days.
The proposed modification should be
described with an estimate given in terms of
days and costs.
The enhancement should be described and
likely release dates should be provided.
Ref
1
2
3
4
5
6
7
8
9
Requirement/Feature
Rating Response
M,I,D A-H
Accounts Payable
Ensure that non-pay payments of the
M
University are processed in an efficient and
controlled manner and in a way that
integrates fully with the other core
modules in the system
Maintain a single set of supplier master
M
records
The application should work on the basis
M
of open and closed items.
Ability to post transactions to the nominal
M
ledger automatically and in real time.
Provide an invoice register.
M
Ability to post an invoice to a number of
M
different cost centres or general ledger
codes.
Ability to integrate purchase orders with
M
commitment accounting, i.e. actual,
accruals and commitments.
Ability to convert commitments/accruals to
M
actual when invoices are processed.
Provide the ability to scan invoices into the
M
system and use electronic signatures for
authorisation.
Vendor Comments
Extent of customisation
• Response to RFT included contractual response to Level
of Fit:
– A : standard functionality
• inaccurate response from vendor may misrepresent the ability of the
software to deliver a functionality
– B, C, E: alternative functionality, workaround or modification
• Notion of workaround misleading : not a once off “fix”
• Total time = workaround time * number of transactions
• Remember the Pareto principle : 10% functionality will
give 90% of headache
How to manage the risk?
• Prioritise functionality : what is the 10%?
• Process for identifying incorrect A’s
• Allocate Bs and Cs to mini-project leaders