Business Processes

1. Business Processes

2. Opening Case- Charles Schwab • Considered the only retail operation to have successfully adapted its business to the Web • Built on the idea of eliminating stockbrokers and providing only transaction processing services • Started offering online trading early (using proprietary software), and was quick to move to Web trading

3. Work Systems Snapshot: Charles Schwab • CUSTOMER • Charles Schwab account holder who buys and sells stocks. • PRODUCTS & SERVICES • Execution of buy and sell transactions • Online stock data and stock analysis • Monthly account reports

4. Work Systems Snapshot: Charles Schwab • BUSINESS PROCESS • Evaluate current status of account • Decide what to buy or sell • Enter the buy or sell order on-line • Receive confirmation of completed trade • Receive monthly reports and other brokerage information • INFORMATION • Market price and purchase price of stocks • Analyst’s reports • Buy or sell orders • Account holder’s current portfolio of stocks, bonds, and other assets • TECHNOLOGY • Personal Computer • Schwab’s hardware and software for tracking portfolios and trades • The Internet (Infrastructure) • PARTICIPANTS • Account Holder • Financial professional (if desired) • Schwab back office staff

5. Introduction • In order to develop information systems or understand them from a business professional’s viewpoint, one needs to be able to describe and analyze business processes. • We will emphasize the relationship between process architecture and process performance. Recall: • Improvements in a work system are usually related to the links between the architecture and the performance perspectives. • Customer satisfaction is largely determined by product performance. • Product performance is determined by a combination of product architecture and the internal work system performance.

6. From work system architecture to customer satisfaction

7. Process Modeling Documenting a Business Process

8. Process Modeling • A business process that involves naming business processes and subdividing them into their basic elements • Helps clarify the problem the information system attempts to solve • Business Process Reengineering (BPR) = the complete redesign of a business process using IT

9. Ford’s New Payables System • New Payables to reduce staff from 500 to 400. • Mazda’s A/P Staff had only 5 individuals. • Differences in the Business Process Model • Consider the degree of structure in Mazda model. • Much of Ford’s A/P Staff time was spent on Exception Processing. • New System requires only 125 persons.

10. Ford’s New Payables System • What changed in the new Ford system? • Are the successes of the Ford and Mazda systems an indictment of management practices in other organizations? • Work System Snapshot

11. Ford Reengineers Its Payables Process • Old process: • The receiving department accepted orders that did NOT match the purchasing order • Lots of overhead to reconcile the inconsistencies • New process: • ONLY shipments that match the purchase order are accepted • The information is entered into a shared database

12. The business process was changed, by eliminating steps that did not add value • The new information system was successful only because of the reorganized work flow

13. Ford’s New Payables System

14. Ford’s New Payables System CUSTOMER Ford’s suppliers Ford’s manufacturing and purchasing departments PRODUCTS & SERVICES Verification that the the order was fulfilled correctly by the supplier Payment to the supplier

15. Ford’s New Payables System • BUSINESS PROCESS • Major Steps: • Order material • Receive shipments • Reconcile receipts with purchase orders • Pay suppliers • Rationale: • store purchase orders in a shared database • accept shipments only if they match the purchase order • pay on receipt, not invoice

16. Ford’s New Payables System PARTICIPANTS Purchasing department Receiving department Accounts payable department INFORMATION Purchase order Receipt confirmation TECHNOLOGY Computer system supporting a shared database

17. Process Modeling: Business Process Architecture • Process Modeling - A method of documenting process architecture by identifying major processes and sub-dividing them into linked sub-processes. • Data Flow Diagrams • Flow charts • Structured English

18. Data Flow Diagrams (DFDs) • Represent the flow of data between different processes within a system • Simple & intuitive, not focusing on details • Describe what users do, rather than what computers do • Limitations: • Focus only on flows of information • Ignore flows of materials, decision points, etc.

19. Figure 3.1 - Symbols used in data flow diagrams

20. Creating Data Flow Diagrams • The starting point for a DFD is a Context Diagram, which shows sources and destinations of the data being used and generated. • Context diagram – bounds the system + summarizes the data flows • The context diagram establishes the scope of the system. • Next identify processes, and break them down into sub-processes to describe how work is done. • Possible to look at a process at any level of detail • The value of DFD’s is in resolving disagreements about how work is currently done, or it should be done in the future. • Example: Ford Accounts Payable.

21. Figure 3.2 - Context diagram for the Ford purchasing system

22. F 3.3 - Data flow diagram showing the main processes in Ford’s original purchasing system

23. F 3.4 - Data flow diagram dividing PCH 1 into four subprocesses

24. Example Data Flow Diagram: Student Grading Final Grades REGISTRAR’s OFFICE STUDENTS Current Grade Test Scores Current Score CALCULATEUNIVERSITYGRADES CALCULATECLASSGRADES TEACHER Final Grades Final Score CLASS/GRADEFILE STUDENTFILE

25. Other Process Modeling Techniques • DFD’s are used extensively. However, other techniques can also be used to fill in some details not expressed by DFD’s. DFD’s do not express the sequence and timing of processes nor the detailed logic of processes. • Flowcharting - represent the sequence and logic of procedures • Structured English - “pseudo-code” - represent the precise logic of a procedure by writing it down.

26. F 3.6 – Flowcharts demonstrate conditions

27. Please note… • Idealized business process – the way the process is supposed to work • Assumes that the participants follow the rules • Workaround – a divergence • Necessary when the rules built into the system become an obstacle to getting the work done • May indicate a poor design or that an external change has occurred

28. Reality Check • Can you identify a business process that was overly idealized and you had to develop a “work around” in order to accomplish a goal?

29. Process Characteristics

30. Architectural Characteristics of a Business Process • Eight Characteristics that often affect business process performance: 1. Degree of Structure • Range of Involvement • Level of Integration • Rhythm • Complexity • Degree of Reliance on Machines • Prominence of Planning and Control • Attention to Errors and Exceptions

31. #1: Degree of Structure • The extent to which a task or business process can be scripted in advance, e.g., • Order of steps • Required information • Validation • Relationships between inputs and outputs

32. Structured Tasks • Structured task = possible to exactly specify how the task is to be performed and the evaluation criteria • Ex.: totaling invoices, ATMs, etc. • information requirements known exactly • methods of processing known precisely • desired format of information known exactly • decisions or steps within the process are clearly defined and repetitive. • Criteria for making decisions clearly understood. • Success in executing the task can be measured precisely

33. Semi structured Tasks • Semistructured task – information requirements and procedures are generally known, but some aspects rely on human judgment • Ex.: medical diagnosis

34. Unstructured Tasks Unstructured task – cannot specify what information is to be used, how to use it, nor what the evaluation criteria should be • so poorly understood that the information to be used, method of using the information, criteria for deciding when task is done can not be specified. • Unstructured tasks are performed based on experience, intuition, trial and error, rules of thumb, and very qualitative measures. • Ex.: choosing a picture for the cover of a fashion magazine • The desired degree of structure is sometimes a matter of controversy

35. Figure 3.7 - Structuring loan authorization

36. Successful Information systems impose the amount of structure appropriate for the task being supported • Too much structure stifles creativity • Too little structure may lead to inefficiencies and errors

37. DEGREE TO WHICH STRUCTURE IS IMPOSED • Highest: Substitution of technology for people • High: Enforcement of rules or procedures • Low: Access to information or tools • Problem if the level is too high: • People doing the work are prevented from their judgement. • People doing the work feel like cogs in a machine because they have too little autonomy. • Problem if the level is too low: • Easily foreseeable errors occur because well-understood rules are not applied consistently. • Outputs are inconsistent. • Review Table 3.2 – p. 98.

38. #2: Range of Involvement • Refers to the organizational span of people associated with the business process • Too narrow decisions are made from a local viewpoint, often missing enterprise-wide opportunities • Too wide business processes slow down

39. RANGE OF INVOLVEMENT • too many participants or too few • the organizational span of people involved in a process. • RANGE OF INVOLVEMENT • Problem if the level is too high: • Work is slowed down because too many people get involved before steps are completed. • Problem if the level is too low: • Work is performed based on narrow or personal considerations considerations, resulting in decisions that may not be the best for the overall organization. • The Role of Information Systems: • Information systems can be designed to broaden or constrict the range of involvement. • Executive Information Systems • Case Manager Approach • TQM: Reduce involvement and empower workers • Note separation of duties from an internal audit perspective.

40. #3: Level of Integration • Often a confusing term • The right level of integration is not obvious • Too little disorganized & unproductive • Too much complex & hard to control • INTEGRATION = mutual responsiveness & collaboration between distinct activities or processes • Related to the speed with which one responds to events in the other

41. #3: Level of Integration • Integration is the mutual responsiveness and collaboration between distinct activities or processes. • In general, the extent of integration between two processes or activities is related to the speed with which one responds to the other. • The speed depends on the immediacy of communication and the degree to which the process responds to the information communicated. • e.g. level of integration between NJIT Registrar and Rutgers-Newark Registrar • Five Levels of Integration: • common culture • common standards • information sharing • coordination • collaboration

42. Five levels of integration • Common culture • Shared understandings & beliefs Common standards • Using consistent terminology & procedures Information sharing • Independent business processes can share each other’s data • Coordination • Separate but interdependent processes respond to each other’s needs and limitations • Collaboration • Strong interdependence; the unique identity of each process begins to disappear

43. Five levels of integration between business processes

44. Five levels of integration between business processes - continued

45. Five levels of integration between business processes - continued

46. Level of Integration • LEVEL OF INTEGRATION • Problem if the level is too high: • Steps in the process are too intertwined. • Participants in different business processes get in each other’s way. • To change one step it is necessary to analyze too many other steps or processes. • Problem if the level is too low: • Steps in the processes are too independent. • The process needs greater integration to produce results.

47. #4: Rhythm • The frequency and predictability with which a process occurs • Periodic • Event-driven • Haphazard • E-business makes it possible to support more responsive business rhythms

48. #5: Managing Complexity • Complexity – how many types of elements the system contains + the number and nature of their interaction • Complex systems are difficult to develop and understand • Difficult to anticipate the consequences of changes

49. How to handle complexity? • Eliminate low value variables • Different versions of processes and information that exist simply because of historical accident • Recognize variations explicitly and treat them differently, instead of using a fundamentally similar process

50. Complexity • Systems that are too simple don’t handle the complexity of the problem; systems that are too complex are hard to understand, maintain, and fix. • Complexity can be measured by the number of elements it contains, and the number and nature of their interactions • Reduce Complexity by reducing low value variations, reducing the number of interacting components, and simplify the nature of interactions. • COMPLEXITY • Problem if the level is too high: • Participants, managers, and programmers have difficulty understanding how the system operates or what will happen if it is changed. • Problem if the level is too low: • The system cannot handle the different cases that it should be able to handle.