from BPRto BPMo

a

intro

2009 trends in IT

McKinseyFive trends that will shapebusiness technology in 2009

r

IT and corporate finance convergeTension around IT budgets increasesThe “last” IT project?Regulators demand more from ITThe offshoring and outsourcing landscape shifts

a

GartnerMeeting the Challenge:The 2009 CIO Agenda

r

Business PrioritiesBusiness process improvementTop 10 Technology prioritiesBusiness intelligence

a

McKinseyIT's unmet potential

a

Cutter BenchmarkEA resolutions for 2009

a

2009 hypes and buzzwords

IBM: smarter planet

ATOS: sustainability

Oracle: green enterprise

EDS: Enterprise cloud

SOA is Dead

r

(Anne Thomas Manes)

a

SOA obituary

(The Acronym) SOA is (Perhaps) Dead (at Some Companies);Long Live Services

a

course classes

week1class1

EA as StrategySystemic Model

Operating Model

r

1) How much standardization do you need?2) How much integration do you need?2*2Business Process IntegrationvsBusiness Process StandardizationH-HUnificationCentralized operationsUnified decisions about IT and business processes Integrated customer interfaceSeamless supply chainH-L CoordinationSemi-autonomous specialized organizational unitsDifferent IT and business process needsCommon view of company demanded by market shared view of customers needed internallyL-HReplicationIndependent business units in a controlled environmentCentralized IT and business decisionsHighly standardized processesL-LDiversificationAutonomous organizational units with different market requirementsIndependent business process and IT decisions Few standards mandated internally

EA vs IT A

r

EA refers to the high level logics governing both business and IT capabilities IT architecture involves: Processes architecture Data architectureTechnology architecture Application architecture … which is almost the same as before but with a technical focus (no customers)

week1class3

SOA maturity stages

r

fundamental SOAnetworked SOAprocess-enabled SOA

week2class2

skepticalenterprisearchitect

r

The Skeptical Enterprise Architect1. Don’t be blinded. Fundamental transformation to the tasks performed inorganizations depend on political and institutional determination.2. Understand the business. Understand the environment, agencyprograms, and potential ‘obstacles’ before launching EA programs.3. Don’t follow, lead. Perceived ‘best practices’ are not always the rightmedicine in a specific context. EA programs must proactively becustomized to a specific context if success is to be achieved.4. Focus on business and leadership, not technical frameworks. NewEA programs must ensure management backing and focus on businessprocess management and change management.5. Only use EA as a toolbox. EA is a meta-discipline that embraces,supplements, and extends other disciplines. EA programs must changeover time and become part of a continuous business improvement agenda.6. Create clear governance structures. Unclear distributions of power,unclear mandates, and a constant struggle for political support will hinderEA success. A clear governance structure across levels and functions ofgovernment is key for successful EA adoption.7. Think big and start small. Develop EA programs that can embrace theneed for extra-organizational horizontal and vertical linkages.EAGov.org Perceived ‘best practices’ are not always the rightmedicine in a specific context. EA programs must proactively becustomized to a specific context if success is to be achieved.EAGov.org

EA projects fail- because- what to do

r

Lack of an understanding of what EA is/isn’t:• EA Training, Develop an EA Communication PlanUnclear leadership:• Assign an Executive Sponsor and Chief ArchitectInsufficient resources:• Proper planning, sufficient budget/time/staff, use EVM trackingThe architecture scope is too big:• Divide the EA into segments, sequence developmentLack of perceived value:• Identify purpose of EA, how value is derived, ROI periodLack of use when architecture is developed:• Integrate into governance, recognize as authoritative standardCompetition with other best practices:• Identify EA as meta-model/context for other practices/methods

EA governancelifecycle

1. EA Engagement

r

Big Tent• Portfolio management framework (PPM andothers)• Project model and project framework (PRINCE2,PMI and others)• Process description framework for business andIT (BPMN and others)• IT operational framework (ITILv3, MOF andothers)• Technological frameworks and tools (to someextent)Engagement questions• Are strategy and initiatives in business and ITaligned?• Are resources used in the best way possible?• Does everyone understand how IT objectivesare supporting the business objectives?• Are risks (business and IT) understood andmanaged?• Are business requirements and qualityexpectations met appropriately?

2. Execution

3. Prioritization

r

• Portfolio management• Herding cats• Drivers– Adjusting the business to new products and serviceofferings– Trends in industry or technology– Economic shifts, tighter budgets, eliminatingredundancies while maximizing reuse– Optimizing the enterprise's operating model– Regulation requirements.

4. Audit

week2class3

EA and business capabilities

r

Building dynamic business capabilities with IT infrastructures: 7 hurdles1.IT Seen Primarily as an Enabler of Operational Capabilities2.Improvisation Seen as Unacceptable3.IT Not Woven Into the Enterprise’s Business Fabric4.Limited Availability of IT Infrastructures5.Difficulty of Funding Emerging IT Infrastructures6.Resistance to Loose/Tight Coupling7.The Temptation to Cut Corners

BPM

r

BPM: main elements•Designing and modelling•Executing and automating•Monitoring and optimizingBPM approaches•Tactical approach–Addressing specific problems in a single business area–Still need for integration and flexibility•Strategic approach–BPM solution set or portfolio–Need for full interoperability among its component parts–Rich capabilities for users, managers, developers–Broad array of capabilities addressing different process types: •Collaborative •Transactional •Structured •Content-centric •Dynamic–Realtime visibility across processes–Can not only optimize existing processes, but help define parameters for new processes•SOA as an enabler for a strategic approach to BPM--> The strategic value of SOAA resource-based model (Mata, Fuerst and Barney 1995)

week4class1

EA project by projectNiels Fonstad

methodologies at the strategic level

kaplan and nortonbalanced scorecard

BPM suites

Gartner's 2009magic quadrant

a
class discussion

class discussion

want to add your comments? go tohttp://www.mindomo.com/edit.htm?m=87f5f2bd510c4deca02abb8198a425c9to edit the map

want to add your comments? go tohttp://www.mindomo.com/edit.htm?m=87f5f2bd510c4deca02abb8198a425c9to edit the map

is any perspective goodfor any BP?critical aspects

the purpose of the modelling

r

if the purpose of the modelling is communication, then a driver to the decision of which perspective and technique to be used should be the simplicity of representation (i.e. if the purpose is communication, ER diagrams or UML diagrams may be ok)

do you agree?

Aurelio

r

ok, but

the value of the process

r

a certain perspective may allow to make more explicit the value of the business process: to include in the representation aspects that are core for the success of the business process--> link to KPI of the BP (and in general to the issue of measurment besides the issue of design)

do you agree?

size of the BP

r

if the BP is small (not much complex)then it is ok to model as a deterministic machine

do you agree?

Aurelio

r

arguable: independently on the size of the process, if you represent it as a deterministic machine you miss several aspects:- evolution along time- social aspectsand these aspects may impact critically on the performance of the BP

legal norms on the BP

r

if the process is normed by the Law, then it can only be seen as a deterministic machine

do you agree?

Aurelio

r

arguable: maybe the truth is that a procedure in a Public Administration is specified (it implements) a mechanistic perspective.But this does not mean that by using another perspective (e.g. to the other extrem, the "Social construct") it would not be possible to improve the process. E.g. is the performace of the BP of deliveriing a certain certificate influenced by the - attitude- skills- morality (?)of an employee, independently on the procedure he/se is ***supposed*** to implement

perspectives on BPs

Melao and Pidd 2000'sframework

examples of BPsuseful for discussion

ATMmachine

r

does an ATM necessarily require a mechanistic view of the BP, or (like in the case of the Public administration), it simply implements the perspective of the deterministic machine?maybe we could improve the output (the service) provided by the ATM if we would look at it from a sociological perspective! e.g. if we take into acconnt the psychological carachteristics of the users of the ATM?

restaurant

r

the BP of a 3 michelin stars restaurant probably implement a mechanistic viewthe BP of an Italian trattoria probably implement a social contruct viewthis does NOT mean that these two are respectively the only "right" perspectives to design the BP.We should ask whther, in order to improve the perfomances of the restaurant, i.e. of its BPs, a Ritz-Carlton sohuld try to use the social construct perspctive and the Trattoria should try a deterministic perspectiveThis lead to discussing what are the variables that influence the choice of one prevalent perspective instead of the others: - the skills of the modeller- the strategic objectives of the organization- ...???

granting a loan

r

typically this BP has a formalized "mechanistic-like" procedures, but includes a strong social variable ("the look in the eye of the customer")therefore to model this process the pure mechanistic perspective would not be enough (it would miss an aspect, the "look in the eye") that is critical for the success of the process

important issues

do not confuse the implementaion of a perspective with the perspective

r

e.g. how the ATM machine works is the "actual" BP, the implementation of a perspective, it is NOT a perspective

as-is vs to-be processes

r

in an AS-IS BP, one could recognize the implementaion of a primary perspective (e.g the deterministic for the ATM)to identify aTO-BE BP, it is useful to start from a different perspectivethere are anyway BPs that require to be modelled according to more than just one perspective