The Implementation of BPR Pertemuan 9 Matakuliah: M0734-Business Process Reenginering Tahun: 2010.
INTRODUCTION Pertemuan 2 Matakuliah: M0734-Business Process Reenginering Tahun: 2010.
-
Upload
patrick-campbell -
Category
Documents
-
view
216 -
download
3
Transcript of INTRODUCTION Pertemuan 2 Matakuliah: M0734-Business Process Reenginering Tahun: 2010.
INTRODUCTIONPertemuan 2
Matakuliah : M0734-Business Process ReengineringTahun : 2010
Process Foundation Phase
Process Foundation Phase :Why ?What ?How ?OutputsRisks
3
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
What ?Process guidelines are the translation of organization values to the process domain
Includes :Ownership of the processScope of the processSelection of a modeling methodSelection of a process modeling and management toolMethod of governance of the process
Process models are visual representations of high-level processes as well as the high-level links betweenprocesses
5
How ?
6
Step 1 : Strategy and Business Information
Overall Objectives and General Principles as specified in 1st 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
Step 2 : Process Guidelines and Models
8
Step 3 : Obtain Relevant Information and Technology Principles and Models
Data Models
Main applications and related interfaces
Main Middleware
Main Platforms
Main Network
9
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-off10
Step 4 : Consolidate and Validate it (Org. Rel. Map)
11
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
Step 6 : Apply it
“The ultimate test for any architecture is what themanagement decides to do in the case of aproject wanting to deviate from the agreedprocess architectural principles.”
13
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
Outputs
A documented and agreed processarchitecture A project start architecture An organization process view A list of end-to-end processes
15
RisksRisks Mitigation Strategy
Too much focus on IT Start with the organization objectives and strategy, and involve management and the business
Too detailed Start with the organization objectives and strategy, and work down to the generic principles
Not used Ensure that the architecture meets the requirements of the management and other stakeholders, and ‘sell’ the benefits to them
Too late Emphasize the importance of a dynamic and compact architecture rather than a meticulous architecture that is difficult to adjust
No Action, Talk Only Approach Architecture as a project, with a clear deliverable and deadline
16
Technology Foundation Phase
Technology Foundation Phase :Why ?What ?How ?OutputsRisks
17
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 needsRequired Tools and Technology is available as well as the skills and experience of IT personnel to develop and maintain themBusiness functionality (services) portfolio is in place to support cataloguing of business servicesData dictionary and transformation among enterprise application is clearly understood and canonical data model is in place
18
What ?
Looks complex ?Ineffective ?
Yet, sounds too familiar…
Recommended Architecture based on service Oriented Architecture :
19
What ?
Recommended Architecture based on Service Oriented Architecture :20
How ?
21
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 implementMiddleware solution within the organization
• Ensure the project team is equipped with sufficient knowledge, skillsand experience require to implement and develop the middlewaresolution
Identify key person/team for Middleware solution
22
Step 2 : Tools and Technology Establishment
• Engage and select vendor to provide middleware solution for yourorganization
• 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
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
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 ofthe 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 andapplied?• Technical background of the data sources
Canonical Data Model and Data Transformation Rule
25
Step 4 : Canonical Data Model and Data Source Dictionary
26
Step 5 : Initial Business Functionality (Services) Portfolio
• Identify and catalogue them• Consider using a mature service registry solution and adhering tostandards
Identify business functionality (services) from various facets of the system
• The person/team needs to be familiar with service cataloguingactivities 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 cataloguingpractices within the organization• Always keep service catalogue clear, concise, and up-to-date• This allows for easy finding and utilization of the services in theregistry 27
Outputs
IT Architectural View and Blue Print Establishment of required tools andtechnology Identification of existing relevant
legacy systems Canonical Data and Data Sources
Dictionary Initial Business Functionality (Service)
Portfolio Establishment of required technical
project team
28
RisksRisks 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