Matakuliah
Tahun
: M0734-Business Process Reenginering
: 2010
INTRODUCTION
Pertemuan 2
Process Foundation Phase :
Why ?
What ?
How ?
Outputs
Risks
Process Foundation Phase
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 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
highlevel processes as well as the high-level links
between
processes
5
How ?
6
Step 1 :
Strategy and Business Information
Overall Objectives and General Principles as
specified in 1st Phase (Completed and Updated
whenever appropriate)
Relevant Business (Products and Services) and
Organization Guidelines and Models
•
•
•
•
Products and Services
Customers
Pricing and Discounting
Partners (including Suppliers) and distribution
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-off
10
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 the
management decides to do in the case of a
project wanting to deviate from the agreed
process 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
process
architecture
 A project start architecture
 An organization process view
 A list of end-to-end processes
15
Risks
Risks
Mitigation Strategy
Too much focus on IT
Start with the organization objectives and strategy, and involve
Too detailed
Start with the organization objectives and strategy, and work down
Not used
Ensure that the architecture meets the requirements of the
and ‘sell’ the benefits to them
Too late
Emphasize the importance of a dynamic and compact architecture
architecture that is difficult to adjust
No Action, Talk Only
Approach Architecture as a project, with a clear deliverable and
16
Technology Foundation Phase :
Why ?
What ?
How ?
Outputs
Risks
Technology Foundation Phase
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 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
What ?
Recommended Architecture based on service Oriented Architecture :
Looks complex ?
Ineffective ?
Yet, sounds too
familiar…
19
What ?
Recommended Architecture based on Service Oriented Architecture :
20
How ?
Initial
Business
Functional
ity
(Service)
Portfolio
Canonical
Data
Model and
Data
Sources
Dictionary
Architectural
View and Blue
Print
Legacy
Systems
Identificati
on and
Analysis
Tools and
Technolog
y
Establishm
ent
21
Step 1 :
Architectural View and Blue Print
Which Enterprise Architecture is selected ?
• Service Oriented Architecture
• How Enterprise Architecture supports Business Process Management
initiatives?
• How Business Process Management initiatives are aligned with
Organizational and Process Foundations?
Identify key person/team for Middleware solution
• 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
22
Step 2 :
Tools and Technology Establishment
Identify Middleware Solution
• 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?
Standards adopted for the organization
• XML-based standard, e.g. WSDL, BPEL, etc.
• Security Standard and Interoperability Standard
• External B2B standard, e.g. eBXML, RosettaNet, etc.
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
Identify involved Legacy System
•
•
•
•
•
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 stakeholders and maintenance team of the
legacy system ?
• Developer of the legacy system
• Maintenance of the legacy system
24
Step 4 :
Canonical Data Model and Data Source Dictionary
Identify involved Data Sources
•
•
•
•
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 maintenance team of the data sources
• Developer of the data sources, including required documentation of
the data, e.g. ERD, DFD, etc.
• Maintenance of the data sources
Canonical Data Model and Data Transformation Rule
• 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?
25
• Technical background of the data sources
Step 4 :
Canonical Data Model and Data Source Dictionary
26
Step 5 :
Initial Business Functionality (Services) Portfolio
Identify business functionality (services) from various facets of
the system
• Identify and catalogue them
• Consider using a mature service registry solution and adhering to
standards
Identify a person/team responsible in establishing and
maintaining service catalogue
• The person/team needs to be familiar with service cataloguing
activities and standards
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
27
registry
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
Risks
Risks
Mitigation Strategy
Complicated Middleware
Opt for one vendor solution if best-of-breed is too complicated, make
technical journals and obtain sufficient knowledge when selecting a
middleware consultant whenever possible
Standard and interface
Focus on the required standards, evaluate popular and well-
Lack of technical skills and
Ensure proper training of technical team, provide sufficient time for
technical skills, focus on small PoCs, consider hiring an experienced
Insufficient documentation and
base of legacy systems
Consider contacting the team that developed the system or perform
sufficient information about the legacy system to externalize it
29