Similaire à Digitalizing the public organization: Information system architecture as a key competency to foster innovation capacities in Public Administration
Similaire à Digitalizing the public organization: Information system architecture as a key competency to foster innovation capacities in Public Administration (20)
Digitalizing the public organization: Information system architecture as a key competency to foster innovation capacities in Public Administration
1. Digitalizing the public organization:
Information system architecture as a key
competency to foster innovation
capacities in Public Administration
Claude Rochet
Professeur des universités
Institut de Management Public et de Gouvernance Territoriale, Aix-en-Provence
3. Tallinn,
May 2011
Claude Rochet
3
eGov is not « putting lipstick to a
bulldog »
NPM & neoclassical economy: I.T. as
manna from heaven
On the contrary, IT operate in a
Schumpeterian mode: through innovation
and endogenous change.
Technology is “nature organized for our
purposes” (B. Arthur) => We must define
those purposes
“Technology is knowledge”: an
evolutionary process between techné and
logos
4. Tallinn,
May 2011
Claude Rochet
4
The Baconian approach
Bacon: Knowledge as a process that must rely on
both theoretical and empirical knowledge.
If real knowledge “takes away the wildness and
barbarism and fierce of men’s mind”, a superficial
knowledge “does rather a contrary effect” (1605).
The real knowledge implies experimentation and a
round trip to theory.
This process must be guaranteed by the state, as an
architect of the numerous initiatives in research
activities, through appropriate institutions: Royal
society in England (1660) and Académie des
sciences in France.
5. Tallinn,
May 2011
Claude Rochet
5
We have forgotten the Baconian
tradition
“The application of inductive and experimental
method to investigate nature, the creation of a
universal natural history, and reorganization of
science as a human activity” (Mokyr)
Consequences:
Failures in IT projects, not specific to the public
sector
Amplified in the public sector:
Quantity of big projects
Heterogeneous data
Number of stakeholders
Moving perimeter
7. Tallinn,
May 2011
Claude Rochet
7
Rules to fail in eGov’t: UK
Classification of non-performing countries
-0,4
-0,2
0
0,2
0,4
0,6
0,8
1
1,2
NL Ca USA NZ JP A UK
De#emphais*on*open
compe. . on
Domina. on*of*large*fir
m
s
In#house*technological
capaci. es
Logarithmique*(Domina. on
of*large*firms)
Logarithmique*(In#house
technological*capaci. es)
Logarithmique*(De#emphais
on*open*compe. . on)
De-emphasis on open competition
Capture by providers
Segmentation b agencies
Domination of large firms:
Globally correlated with high costs
NZ: counterbalanced by the small
market size
US: counterbalanced by the SBA.
In house technological capabilities
Internal expenses > 50% NL, CA
NL: Innovation through interaction
with provider, thank to an
architecture of small market
The strongest value creation lever
Standard
market
costs
Conclusions:
- No universal model: national characteristics matter
- Poor technology transfer and learning process
- In-house technological capacities is the key
Conclusions:
- No universal model: national characteristics matter
- Poor technology transfer and learning process
- In-house technological capacities is the key
8. Tallinn,
May 2011
Claude Rochet
8
NPM is inappropriate for ICT
deployment !
UK: NPM’s Kingdom
Outsourcing based
on costs
Lost of
competencies to the
profit of providers
Oligopoles
No innovative
capacity creation
Netherlands
• Partnership and negociations
• Strong IT competencies whithin
the buyer
• Innovation in the margins of
customer - provider relationship
Netherlands
• Partnership and negociations
• Strong IT competencies whithin
the buyer
• Innovation in the margins of
customer - provider relationship
Source: Dunleavy &Margetts, LSE
9. Tallinn,
May 2011
Claude Rochet
9
No correlation between success and
amounts of investments
The success relies in
architecture design through
interaction with users
12. Tallinn,
May 2011
Claude Rochet
12
Why so many failures?
Originally specified features available according to
the size of the organization
41%
36%
23%
Small
Medium
Large
The bigger the projects, the worse the results:
13. Tallinn,
May 2011
Claude Rochet
13
Unrealistic expectations from
politicians who favor spectacular
projects
Technology is thought to be a
problem solver in itself without
rethinking the processes
Managers see the problem of
digitalizing the organization as a
technical problem. They consider only
the emerged part of the iceberg.
IT projects are not seen as
processes reengineering tools that
upset the current organization
Why so many failures?
General Chaos report reasons to fail Public sector context
14. Tallinn,
May 2011
Claude Rochet
14
Innovation in processes Innovation in I.T
Opens new avenues for
Calls for alignment of
Endogenous innovation Endogenous innovation
May do (strategy pulled)
Can do (techno pushed)
Understanding technology as an
evolutionary process
15. Tallinn,
May 2011
Claude Rochet
15
Framework: An isomorphism between the IS and
the organization
SoftwareHarware
Organization
Business processes
General management
CIO
Technical
system
Organization
Business, R&D
Organization
Information
system
IT strategy
implementation
Business
processes
Technical system
ProvidersCompetitors
Exogenous
innovation
Stakeholders
Strategic and
innovation
system
Institutional
framework
Strategic
stakes
Innovation
policy
Innovation
opportunities
18. Tallinn,
May 2011
Claude Rochet
18
Mapping the systems tree structure
Computer Infrastructure
External systems
Computing system
Information
system
Environment
Softwares
Organization
(people)
Business systems
Defining outside and
inside is a key issue in
systems mapping
21. Tallinn,
May 2011
Claude Rochet
21
First balance, made with
participants
Strenghts:
It’s crystal clear!
The sequence of
concepts is natural
It’s ready to use
The triangle is limpid!.
The methodology allows
going form the global to
the detail
Even a beginner in
architecture may apply it
Case studies and
testimonies.
Weaknesses:
The problem of poor
support from the
management remains
unsolved, in spite of the
high price of this training,
although the immediate
impact on the daily
performance is visible.
The program reveals this
lack of support stronger
since architecting process
needs to present trade-off.
We are thinking in a special
short session for top-
executive to explain what
their role is.
22. Tallinn,
May 2011
Claude Rochet
22
Some basic (best?) practices
identified
1- Practice modeling to solve a specific problem, not for the pleasure of building a model using the
latest up-to-date tool.
2- Modeling architecture is a key part of any IT project, and this, since the very beginning.
3- Stay KISS (keep it short and simple) : do we need that? For which purpose?...
4- An information system is a virtual reality, not the “real” real, so there will always remain many
uncertainties that must be permanently explored.
5- Never forget any human and technique dimension of a project!
6- A modeling process is effective only if it fosters iteration between the clients and the architect.
7- There is no black box: clients must be associated in every task of the design process.
8- A model needs to be stable but not congealed: it is an ongoing process that may be capable of
evolution as we approximate the real of the real: it is the condition for the model to be
trustworthy.
9- The sooner the better: begin with a simple model that will be sophisticated as the project
advances.
10- A big grain model is more useful than an unreadable but complete model.
11- Experience is key!!! We estimate than at least ten years of business practices is necessary to
begin with architecting.
12 -Once designed, a model is an asset of the organization, a building block that will improve further
modeling
24. Tallinn,
May 2011
Claude Rochet
24
“Baconizing” eGov’t management
Classical
Baconian
activities
Description
Digitalized
Baconian activity
Counting Gathering the data, tasks, units of
works, procedures, softwares
(legacy), lines of code…
Computing
Classifying Libraries of (on the shelves)
processes, routines, sub-
systems, functions, applications,
urbanization plan…
Charting
Categorizing Grouping processes, building
blocks, aligning business and IT,
architecture, testing
Conceiving
25. Tallinn,
May 2011
Claude Rochet
25
Interventions scenarios
Charting the means allocations banks of
processes
Agile and scalable processes
Intervention systems
RETEX Relevant Interventions
Improvement
SIG Météo France
Cellules FIRE
Linking exogenous and
endogenous innovation
26. Tallinn,
May 2011
Claude Rochet
26
Pôle 1
Pôle 2
Pôle 3
Pôle 4
Pôle n
Terri
-
toire
Terr
i-
toire
Terri
-
toire
Terri
-
toire
Terri
-
toire
Terr
i-
toire
Indicateurs
de
processus
Indicateurs
de
processus
Indicateurs
de
processus
Indicateurs
de
processus
Indicateurs
de
processus
Adding value by
architecture
Process
reengineering
Integrating all the
services in a one
stop shop
Projet « Maison du
Rhône Numérique »
Adding value by
architecture
Process
reengineering
Integrating all the
services in a one
stop shop
Projet « Maison du
Rhône Numérique »
Focusing the “Maison du
Rhône” on high value
service delivery
Automatizing
processes building
blocks through the
web
1 2
Distribution des
prestations
Conception et
pilotage des
prestations
Digitalized
house of
departmental
services
27. Tallinn,
May 2011
Claude Rochet
27
IT management: a lever for
institution evolution
As Bacon put it four centuries ago, the success of a
nation doesn’t rely on race, climate, geography or
natural resources but on his ability in arts defined
as the capability to stimulate the production and
selection of useful knowledge through a permanent
round trip from epistemic knowledge to empirical
practice.
Good institutions – rules of the game – for
creating value using IT will emerge from this
process of digitalizing public administration.
Notes de l'éditeur
North emphasizes on the consequences of a mismatch between informal and formal constraints “When there is a radical change in the formal rules that makes them inconsistent with the existing informal constraints, there is an unresolved tension between them that will lead to long-run political instability” (North, 119, p. 140). It would not suffice to create appropriate formal rules if informal rules don’t evolve. Analyzing the origins of English success in the first industrial revolution, North insists on the role of such informal constraints that were hospitable to change in formal rules. In the present technological revolution, decision of implementing IT in public organizations would limit in putting “lipstick on a bull dog” if informal constraints and culture didn’t evolve to allow business model to transform. In other words, crisis, if properly managed as a learning organizational process is an opportunity to enhance organizational paradigms,