Enterprise Business Processes and Applications (IS 6006) Masters in Business Information Systems 6 th 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 SalesShippingCollect cashProduction Customer information (ship-to, bill-to, install-at, …)

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 –… ERP “hardwires” processes 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 General Ledger Accounts Payable Accounts Receivable PurchasingCash Fixed Assets Budgeting and Forecasting Reporting

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: *MMandatory *IImportant; *DDesirable (‘nice to have’)

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