2. INTRODUCTION Pertemuan 2 Matakuliah: M0734-Business Process Reenginering Tahun: 2010

3. Process Foundation Phase Process Foundation Phase :  Why ?  What ?  How ?  Outputs  Risks 3

4. Why ? Ensuring the processes are aligned with : Organization’s Objectives and Organization Strategy The way the business is (or should be) performed in order to provide the products/services to customers The IT architecture and applications Related supporting processes All relevant information are grouped together and available Relevant decisions and high-level processes are presented in an easily understood manner 4

5. What ? Process guidelines are the translation of organization values to the process domain Includes : Ownership of the process Scope of the process Selection of a modeling method Selection of a process modeling and management tool Method of governance of the process Process models are visual representations of high- level processes as well as the high-level links between processes 5

6. How ? 6

7. Step 1 : Strategy and Business Information Overall Objectives and General Principles as specified in 1 st Phase (Completed and Updated whenever appropriate) Products and Services Customers Pricing and Discounting Partners (including Suppliers) and distribution Relevant Business (Products and Services) and Organization Guidelines and Models Helpful ways of obtaining information : Listings of products, prices, customers and partners Annual financial plans, marketing plans, major account plans and bugets Rationale behind selection of products, prices, customers and partners Visualizing the structures 7

8. Step 2 : Process Guidelines and Models 8

9. Step 3 : Obtain Relevant Information and Technology Principles and Models Data Models Main applications and related interfaces Main Middleware Main Platforms Main Network 9

10. Step 4 : Consolidate and Validate it Use the organization objectives and strategy as a starting point Add all the various requirements and views of the stakeholders Highlight the relationships and conflicts between these requirements Discuss the conflicts, and find ways or alternatives of how to deal with these Prioritize the requirements Discuss process gaps and remaining conflicts Prepare action plans to deal with the disconnects and conflicts (including escalation paths) Present final findings to relevant management Finalize Organization Relationship Map and obtain sign-off 10

11. Step 4 : Consolidate and Validate it (Org. Rel. Map) 11

12. Step 5 : Communicate it Displaying posters of the architecture models throughout the organization Ensuring that all relevant organization charts use the architecture in their scoping and decision-making Ensuring that projects use the architecture as a starting point 12

13. Step 6 : Apply it “The ultimate test for any architecture is what the management decides to do in the case of a project wanting to deviate from the agreed process architectural principles.” 13

14. Step 7 : Improve it “A process architecture is never finished, it only gets better.” The architecture can be further refined and expanded in the following ways : 14

15. Outputs  A documented and agreed process architecture  A project start architecture  An organization process view  A list of end-to-end processes 15

16. Risks Mitigation Strategy Too much focus on ITStart with the organization objectives and strategy, and involve management and the business Too detailedStart with the organization objectives and strategy, and work down to the generic principles Not usedEnsure that the architecture meets the requirements of the management and other stakeholders, and ‘sell’ the benefits to them Too lateEmphasize the importance of a dynamic and compact architecture rather than a meticulous architecture that is difficult to adjust No Action, Talk OnlyApproach Architecture as a project, with a clear deliverable and deadline 16

17. Technology Foundation Phase Technology Foundation Phase :  Why ?  What ?  How ?  Outputs  Risks 17

18. Why ? Ensuring IT is ready and capable of supporting Business Process initiatives: Existing legacy application can be externalized and service-enabled to support integrated business process management system Integration is conducted in efficient and standardized manner to support agile and transparent business process execution Enterprise Architecture and Blue Print support current business needs and extensible to anticipate future business needs Required Tools and Technology is available as well as the skills and experience of IT personnel to develop and maintain them Business functionality (services) portfolio is in place to support cataloguing of business services Data dictionary and transformation among enterprise application is clearly understood and canonical data model is in place 18

19. What ? Looks complex ? Ineffective ? Yet, sounds too familiar… Recommended Architecture based on service Oriented Architecture : 19

20. What ? Recommended Architecture based on Service Oriented Architecture : 20

21. How ? Architectural View and Blue Print Initial Business Functional ity (Service) Portfolio Tools and Technolog y Establishm ent Legacy Systems Identificati on and Analysis Canonical Data Model and Data Sources Dictionary 21

22. Step 1 : Architectural View and Blue Print Service Oriented Architecture How Enterprise Architecture supports Business Process Management initiatives? How Business Process Management initiatives are aligned with Organizational and Process Foundations? Which Enterprise Architecture is selected ? Developer of the Middleware solution Middleware solution may be one of the most important piece of system within your IT infrastructure as it integrates business applications and runs and automates business processes Identify and form a project office to investigate and implement Middleware solution within the organization Ensure the project team is equipped with sufficient knowledge, skills and experience require to implement and develop the middleware solution Identify key person/team for Middleware solution 22

23. Step 2 : Tools and Technology Establishment Engage and select vendor to provide middleware solution for your organization One provider or best-of-breed? Technical background and availability of technical resources Establishment and Identification of Business Rules Framework How to connect to and mine the data source? Identify Middleware Solution XML-based standard, e.g. WSDL, BPEL, etc. Security Standard and Interoperability Standard External B2B standard, e.g. eBXML, RosettaNet, etc. Standards adopted for the organization Identify stakeholders and maintenance team for the middleware implementation Developer of the middleware solution Maintenance of the middleware solution 23

24. Step 3 : Legacy System Identification and Analysis Which system is involved in the process flow? How is it currently integrated? Life span of the Legacy System Integration options to service-enable legacy system Technical background of the legacy system Identify involved Legacy System Developer of the legacy system Maintenance of the legacy system Identify stakeholders and maintenance team of the legacy system ? 24

25. Step 4 : Canonical Data Model and Data Source Dictionary Which data is required in the process flow? Structured data? Unstructured data? Technical background of the data sources How to connect to and mine the data sources? Identify involved Data Sources Developer of the data sources, including required documentation of the data, e.g. ERD, DFD, etc. Maintenance of the data sources Identify maintenance team of the data sources What data needs to be described in the integrated enterprise level? How would the data be described? What standard will be used to describe the data? Structure, data type, etc. How can the data be integrated? What transformation and integration rules need to be developed and applied? Technical background of the data sources Canonical Data Model and Data Transformation Rule 25

26. Step 4 : Canonical Data Model and Data Source Dictionary 26

27. Step 5 : Initial Business Functionality (Services) Portfolio Identify and catalogue them Consider using a mature service registry solution and adhering to standards Identify business functionality (services) from various facets of the system The person/team needs to be familiar with service cataloguing activities and standards Identify a person/team responsible in establishing and maintaining service catalogue Enforce due-diligence in service cataloguing as you progress throughout the implementation Enforce the IT to always report and adhere to service cataloguing practices within the organization Always keep service catalogue clear, concise, and up-to-date This allows for easy finding and utilization of the services in the registry 27

28. Outputs  IT Architectural View and Blue Print  Establishment of required tools and technology  Identification of existing relevant legacy systems  Canonical Data and Data Sources Dictionary  Initial Business Functionality (Service) Portfolio  Establishment of required technical project team 28

29. Risks Mitigation Strategy Complicated Middleware solution Opt for one vendor solution if best-of-breed is too complicated, make sure to read sufficient technical journals and obtain sufficient knowledge when selecting a solution. Consult experienced middleware consultant whenever possible Standard and interface complexities Focus on the required standards, evaluate popular and well- supported standards Lack of technical skills and experience Ensure proper training of technical team, provide sufficient time for the team to pick up their technical skills, focus on small PoCs, consider hiring an experienced middleware consultants Insufficient documentation and knowledge base of legacy systems Consider contacting the team that developed the system or perform enough code inspection to get sufficient information about the legacy system to externalize it 29