SETLabs Briefings Enterprise Agility

SETLabs Briefings
VOL 4 NO 1
BUSI NESS I NNOVATI ON through TECHNOLOGY
July - Sep 2006
PLATFORMS FOR
ENTERPRISE AGILITY
SETLabs Briefings
Advisory Board
Aveejeet Palit
Principal Solutions Manager,
SystemI ntegration Practice
Deependra Moitra
AssociateVicePresident,
SoftwareEngineering &
TechnologyLabs
Gaurav Rastogi
Global Sales Effectiveness
George Eby Mathew
Principal Researcher,
TechnologyLabs
Kochikar V P
Education & Research Unit
Raj J oshi
Managing Director,
I nfosys Consulting I nc.
Ranganath M
VicePresident & Head,
Domain CompetencyGroup
Srinivas Uppaluri
AssociateVicePresident & Head,
Global Marketing
Subu Goparaju
VicePresident & Head,
TechnologyLabs
I cannot think of a better example for agility than this one from the
thresholds of Pepsicos KFC. During the outbreak of the Avian flu in Asia two years
ago, KFC, known the world over for its vintage chicken recipes, adapted to selling
fish in Vietnam and a few other countries. Or for that matter, consider erstwhile HP
CEO Carly Fiorinas favourite example that HPs printer business can plug in or
plug out a supplier in hours compared to weeks earlier. That is agility requiring
organizations not only to change their supply chains at the blink of an eye but also
change almost everything about the way it does business in response to an
unanticipated environmental factor.
While not many corporations can successfully adapt to adverse
environmental conditions, organizations that do so very well have control over their
business that lends them the ability to conform (adaptability) to a changed
environment and the ability to change course (agility) in challenging environments.
If not for a harsh environment, more and more companies are finding that
cranking a good business model is no longer paying off. Many would recall former
Xerox CEO Paul Allaire famous conference call of Wall Street analysts when he said:
We have an unsustainable business model. A February edition of Fortune Magazine
this year listed Microsoft, Sony, Verizon, Wal-Mart and many more stalwarts of
yesteryears facing this challenge today and called it one of the biggest challenges for
global corporations today. Unless enterprise agility is designed into organizational
DNA, reinventing their outmoded business models or responding to environmental
challenges is a pipedream.
One thing that keeps technologists, researchers and practitioners awake at
night is the quest to find out how IT can help build platforms for enterprise agility
pretty much the theme of this issue of SETLabs Briefings. In fact Davenport, Hammer
and Champy strongly argue that information technology must be seen as one of the
major enablers of organizational change rather than a tool to implement business
processes. IT minimizes business risks by alerting decision makers through
knowledge transport and control mechanisms. IT helps both in the speed and quality
of decision making an asset for agile enterprises. So we cover several of these
themes in this issue.
One of our articles look at how web services and shared data services
improve the quality of decision making in the context of an agile organization. We
cover research on business process management that bridges the gap between
orchestration of business processes on the IT DNA powering processes to ride on
inherent flexibility that IT provides. Examples of agile platforms in banking and
utilities add to the vertical flavors. We felt incomplete without devoting two articles
to software engineering process, project management as well as process design in
the agility context.
We are indeed grateful to Prof Venkat Ramaswamy from the Ross School
of business, University of Michigan, for contributing an extra-ordinary article on
building co creation platforms for value creation a distinct example of how IT can
be used as a platform to partner with customers to create value for the firm in an
ever changing canvas of consumer expectations.
George Eby Mathew
george_mathew@infosys.com
Editor
Agility as an edge
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
11
15
37
49
55
3
SETLabs Briefings
25
45
Tutorial: Adopting Agile Methodologies of Software Development
ByNayan J yoti Kar
Established paradigms of software development are being challenged by agile methodologies
which are increasingly gaining mindshare. The popularity of these methodologies are based on the
fact that the development process espouse values such as simplicity, commication among
developers, and constant feedback from the user community.
Perspective: Business Process Management: Facilitating Enterprise
Agility
ByAkash Saurav Das, Sandeep Gaikwad & Vivek Raut
Bridging the gap between business and technology landscapes is a critical, step to align business
requirements with information technology infrastructure. An effective enterprise BPM
paradigm does just that, and in the process enhances agility.
Trends: Towards Enterprise Agility through Effective Decision
Making
BySriramAnand & Jai Ganesh
Facilitating the executive decision making process through innovative use of emerging
technologies, pays rich dividends. The authors propose an Enterprise Digital Dashboard
architecture framework, which builds on the concepts of Web Services and shared data services.
Third Angle: Co-Creating Experiences of Value with Customers
ByVenkat Ramaswamy
The interactive space between a firm and its customers has the potential to create business
value. The basis of value for the customer shifts from a physical product to the total co-creation
experience. Prof. Venkat Ramaswamy of the University of Michigan, builds a compelling case
for building experience co-creation plat forms.
Viewpoint: Enhancing the Agility for Customer Information System
in Utilities
ByAnanth Chandramouli, Clifton Muhammad & Vivek
Customer I nformation Systems (CI S) play a critical part in the service delivery chain in utility
companies. Managing these systems as their scope enlarges is proving to be a herculean task.
This viewpoint builds a case for enhancing the agility of CI S by focusing on a better
understanding of technology and business drivers, as well as leveraging new technologies.
Viewpoint: How Strategic is building an Agile Enterprise ?
ByVani Vangala
The ability to respond quickly to changing business conditions is critical for enterprises today.
The author argues that enterprises need to become agile for improved performance and
longer life expectancy by treading a multi-fold path to agility.
Practitioners View: Strategic Agility Planning for Banks
ByPrashant Gupta & Prashant Tewari
Robustness and scalability is the key to agile processes in banks. Drawing on their vast
experience in designing systems for some of the worlds largest banks, the authors propose an
agility framework, which will enable banks to implement agility enabling strategies.
Tutorial: Agility in Software Engineering Processes
ByShaurya Vardhan Garg
Writing enterprise software using agile processes helps speed up the software development
lifecycle. The key, the author opines, is to replace processes and tools with individuals and
interactions, and also replace comprehensive documentation with working software.
.
.
Companies must learn to build platforms that enable
experience co-creation processes across the portfolio of experience
environments. I n this view, I T platforms become a strategic
enabler of experience co-creation processes. Experience co-
creation platforms are about creating the pre-conditions to
accommodate a wide variation in individualized experiences
that are contextual and granular.
Venkat Ramaswamy, PhD
Director of theCenter for Experience
Co-Creation, Ross School of Business,
University of Michigan.
One of the challenges that organizations face in their journey
towards agility is their inability to track change drivers
proactively. I t becomes even more difficult for the
organization to do so if they do not have systems, processes
and the data to identify and make judgments on the changes
occurring in their environment.
Prashant Gupta
Senior Consultant
Banking Domain Competency Group
3
Adopting Agile Methodologies
of Software Development
Agile methodologies are challenging established
paradigms of software development.
By Nayan J yoti Kar
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
A
gility in the business context is the ability
of an enterprise to be proactive to changes
happening in the environment in order to
maximize the benefits. The key factors that determine
the degree of agility of an enterprise are:
Level of awareness Keeping abreast of the
changes and being prepared for the same.
I nnovation Quotient (I .Q.) The
percentage of those people whose ideas
finally make it into practice [Skyrme,
David 1998].
AGILITY: PROACTIVE VS REACTIVE
Being proactive has a definite edge over being
reactive. Proactive means setting the pace for
others to catch-up and reactive is exactly the
opposite. Reactive enterprises often find
themselves scampering to meet the challenges set
by an innovative and aware enterprise.
The level of awareness and the I.Q.
would determine whether an enterprise is
proactive or reactive. The relationship between
awareness, I.Q. and agility determine the state
of an enterprise (Figure 1).
As the level of Awareness and I .Q.
increases, the Agility also increases making the
enterprise more proactive.
SIMPLE STEPS TO AGILITY
Agility can be attained using a simple two-step
approach:
1. Handle external factors
2. Formulate Internal Policies
STEP 1: HANDLE EXTERNAL FACTORS
The external environment for an enterprise
includes all the factors that directly or indirectly
impact business operations (Figure 2). Some of
these factors are:
Market: The market conditions are generally
volatile and change dramatically. The reasons for
change might be totally unrelated to the industry.
An Agile Enterprise is not caught
unawares by the rapidly changing market
scenario. It embraces the change and devises
ways to use it to its own advantage. Sometimes,
an Agile Enterprise introduces innovations that
change the market scenario. This results in the
4
realignment of the business plans of its
competitors.
Customer: The customers role has gone through
rapid changes in recent times from being a mere
end-user to playing a more active role in the
development process for the product leading to
co-creation of value.
An Agile Enterprise welcomes the
customer feedback and tries to incorporate them
in the product. It also strives to foresee some of
the changing business needs and provides
suggestions for the same to the customer. This
adds value to provider-customer relationship
and opens new avenues for future business.
Government Regulations: New laws could be
enacted or old ones modified over time that may
impact the business. Usually, such changes are
notified well in advance by the regulatory
authorities. Awareness is the key with respect to
this factor.
Natural Calamities: Natural calamities can be
dealt with by having a business continuity plan
and appropriate disaster recovery initiatives to
prevent a complete shutdown of operations and
ensure that critical activities can keep on running
in face of such a situation.
STEP 2: FORMULATE INTERNAL POLICIES
The Business Enterprise is a synergy of various
smaller units performing different functions.
Agility at the enterprise level can be achieved
when al l these uni ts themsel ves become
Agile. This can be achieved by formulating
policies to govern the functions of the different
units.
I t is very important to formulate a
flexible policy that evolves over time and a policy
that acts as an enabler and not as a limiting factor.
There are various agile methodologies
that provide a framework for formulation of such
policies. These methodologies are primarily
developed keeping software development as
focus. They can be applied to other enterprises
with minor modifications. It is important to note
that there is no best-fit methodology for an
enterprise.
BUSINESS
ENTERPRISE
MARKET
CUSTOMERS
GOVT.
REGULATION
NATURE
Figure 2.
Source:
External Factors Influencing an Enterprise
Infosys Research
AWARENESS & I.Q.
A
G
I
L
I
T
Y
Figure 1: Relationship between Awareness, I.Q. and Agility
Source: Infosys Research
REACTIVE
PROACTIVE
5
POPULAR AGILE METHODOLOGIES
Extreme Programming (XP)
Extreme programming was developed
by Kent Beck when he introduced it in his book
Extreme Programming Explained. It has been
one of the most popular agile methodologies
owing to its simplicity.
Extreme Programming is a discipline
of software development based on values of
simplicity, communication, feedback, and
courage. It works by bringing the whole team
together in the presence of simple practices, with
enough feedback to enable the team to see where
they are and to tune the practices to their unique
situation. [Jeffries, Ron 2001]
The core XP practices which form the
heart of this methodology are (Figure 3):
Whole Team: The team comprises of all the
contributors - the development team (including
a lead), the customer and the business analysts.
The team together determines
What needs to be done?
How?
What is the time frame?
This collective activity ensures that future efforts
would be in the right direction.
Planning Game Planning game lays the outline
for the development of the product. I t is a
characteristic of almost all Agile methodologies.
The activities involved are:
Short iterations of 3 weeks
Frequent Plan updates
Story assignment (a story is a
particular requirement displayed on a 3
X 5 card)
Small Releases Frequent releases with partial
functionality are delivered. This enables the
customer to do an interim review of the product
and suggest changes, if required.
Every release should be as small as
possible, containing the most valuable business
requirements. [Beck, Kent 2000]
Customer Tests: There are a number of customer-
defined tests listed during the whole team
meeting phase. The purpose of these tests is to
validate each release to the customer.
6
Simple Design: A design is simple if it is focused
only on the current functionality and doesnt
consider potential future functionalities.
I f you believe that the future is
uncertain, and you believe that you can cheaply
change your mind, then putting in functionality
on speculation is crazy. Put in what you need
when you need it. [Beck, Kent 2000]
Pair Programming: Pair programming involves
two people working together on development
of a single program. This leads to prevention
and early detection of defects by peer
collaboration.
Pair programming is a dialogue
between two people trying to simultaneously
program and understand how to program
better. [Beck, Kent 2000]
Test-Driven Development: This step involves
developing unit tests in short cycles. At the time
of release, all these tests are run to check program
reliability and each of these tests must pass for a
successful release.
Refactoring: A successful iterative development
process has a good design as the foundation. In
XP, the process of continuous design
improvement is called Refactoring.
The Refactoring process focuses on
removal of duplication (a sure sign of poor
design), and on increasing the cohesion of the
code while lowering coupling. [Jeffries, Ron
2001]
Continuous Integration: XP stresses on the
integration of the units as soon as they are
developed. Integration is never left as the last task.
Late integration invariably complicates the
process and increases defect injection rate.
SCRUM
The Scrum methodology gets its name from the
huddle formed by rugby players to clash with
the players from opposition. It was developed
by Ken Schwaber and Jeff Sutherland. The
primary thought behind this methodology is that
the world is totally unpredictable and hence, it
is impossible to accurately plan for the future.
Scrum relies on self-commitment, self-
organization, and emergence rather than
authoritarian measures. [Schwaber, Ken 1996]
The Scrum methodology revolves around short
30-day iteration called a Sprint (Figure 4). The
Scrum framework is divided into three stages:
Pre-Sprint: The Pre-Sprint stage involves Sprint
planning. This is a process of creating a list of
features to be incorporated in the system. The
owner determines which feature is to be taken
up in the next Sprint. A Sprint Goal is also
Feedback
Loop
Market Customer
Agile Enterprise
Agility Roadmap
Core Team
Business
Enablers
(HR, F&A,
CCD, FAC)
Business
Units
(IHL, APAC,
EMEA)
Agile
Methodologies
(XP, Scrum)
Figure 5.
Source:
A Generalized Approach to Agility
Infosys Research
7
established which provides a purpose to the team
to achieve.
Sprint: Sprint stage leads to the development of
the software. The feature picked up from the list
is implemented in a 30-day cycle. There is a daily
Scrum meeting which improves the visibility of
each persons work. Changes to any feature
during a Sprint are not allowed, except under
extraordinary circumstances.
Post-Sprint: This stage involves customer
demonstration, progress review and technical
review. This stage ensures that the customer
and the team have an early preview to the
system.
At the end of this stage, the entire Scrum
process is repeated.
AGILITY - A GENERALIZED APPROACH
While there are factors and methodologies
contributing to agility, a generalized
methodology can also be adopted to achieve
agility (Figure 5).
A few of the major participant factors in this
approach are:
Core Team: The Core Team takes inputs from
external factors such as market conditions, and
customers etc, to formulate an Agility
Roadmap. This team comprises of selected
people from all units.
Agility Roadmap: The Agility Roadmap is a
framework set by the Core Team for the various
units of the enterprise. It consists of a set of
guidelines which aim to assist the enterprise in
achieving the ultimate goal Agility. The
important point is that the guidelines are not
rigid and can be changed by the target units.
Business Units (BUs): The Enterprise is divided
into various Business Units that have a certain
degree of autonomy. This division could be on
the lines of geography or types of activities. A
BU can be thought of as a mini enterprise
within an enterprise. An Agile BU, on its part,
forms Core Teams at BU level that are responsible
for finding ways to maneuver on the Road to
Agility set by the Enterprise-level Core Team. It
promotes the use of Agile Methodologies (XP, or
Scrum) in all its processes and increases
interaction with customers. An agile BU also
improves or changes the Agility Roadmap and
informs the Enterprise-level core team of the
changes.
Business Enablers: The Business Enablers are the
units that help in smooth operations of the BUs.
Human Resources (HR), Finance & Accounts
(F&A), and so on fall into this category. The
Agility Roadmap sets certain goals for the
Business Enablers which complements the goals
set for the BUs.
Customer: Customer in this approach should be
one who is interested and involved in the product
development. Customer interaction at every level
is an important aspect of an Agile Enterprise. This
not only gives higher visibility of the process to
the customer, but also reduces the inherent
unpredictability of the planning and development
process. However, it should be noted that the onus
is on the Enterprise to appraise the customer of the
progress and get his feedback.
Feedback Loop: The Feedback Loop ensures that
communication channel between Customers &
BUs, Core Team & Business Enablers and Core
Team & BUs is always open.
Agile Methodologies: The functioning of BUs
and Business Enabler units are aided by the Agile
Methodologies such as XP and Scrum. The units
decide which methodology would best fit their
goals on the Agility Roadmap.
AGILITY IN ACTION A CASE STUDY
Consider the case of a mid-size CMM Level 5 IT
solutions company that has bagged an important
contract from a telecommunication major.
8
The Background: A Senior Project Manager of
the IT company is given the overall charge of the
assignment. The project is very important as it
could propel the company in to a big league.
The Problem: The task was to port the billing
systems of the telecommunication company to a
new technology platform with some
enhancements. The existing billing system was
developed on an old proprietary technology,
which will cease to be supported in the near
future. New regulations have also come into
effect that require certain changes to be made to
the system. Both the factors make adherence to
the timelines sacrosanct and strict penalties are
proposed in case of any deviation. The staffing
requirements are intimated as soon as the
proposal is accepted and the requirements
collection phase is started in an earnest. It was
noticed later that a major error in resource
estimation had crept in.
Planned Quick Fix: A project that is bound by
strict timelines simply cannot afford to be short
on trained manpower. The project manager,
therefore, took a two-pronged approach to tackle
this issue:
Recruit trained technical experts
Train the internal resources in tandem
with the requirement collection phase.
The Crisis: But the project went off the track as
the scheduling plan seemed to be in complete
disarray. The requirement collection team is yet
to finalize the requirements and the training plan
was behind schedule and suddenly
compounding the situation was a dearth of
trained people in the new technology. While
initiating corrective measures on the resources
front, the senior project manager dispatched a
manager onsite to gauge the situation there.
The Analysis: A thorough study of the
requirements gathering methods brought some
startling facts to light. The requirements
collection team didnt have a single point of
contact with the client. They were contacted by
multiple people with new ideas on a regular basis
and were swamped with changing requirements
and new requests. Hence, most of the time was
utilized in documentation rather than the actual
work.
The Solution: After a careful consideration of
the situation, a few changes are initiated to instill
agility and solve the crisis. These changes are
aimed not only at solving the issue at hand but
preventing recurrence of such issues in the
future.
The Training department is given a
directive to formulate a policy of in-house
training on latest technologies. The recruitment
policy is modified as it needs to be driven by
certain degree of foresight. If there is a shortfall
of experts on a specific technology, a suitable
Examining requirements gathering methods will indicate
that most of the time is being utilized in documentation
rather than development!
9
number should be recruited from outside. These
steps would make sure that there is no resource
crunch.
The requirements collection process is
streamlined. The client is requested to fix a
single point of contact for requirement changes
and new requirements. The projects which
have frequent requirement changes need to do
away wi th tradi ti onal steps of Software
Development Life Cycle. SCRUM methodology
can be used in such projects to prioritize
requirements.
A part of the requirements will be
frozen for a month. After a month, the client
would get a working prototype of the earlier
frozen requirements. Now, another set of
requirements would be taken up on priority
and this process of iterative development will
go on. The priority will be decided by the client.
The team i s asked to document onl y the
absolutely necessary information. These steps
would ensure that priceless time is saved and
client would get a preview of the system long
before the final implementation.
The learning from this project forces the
organization to give a serious thought to Agile
Methodologies. A central co-ordination team is
formed to rollout an Agile strategy for the
future.
The Impact: Two months later, the IT project
team successful l y del i vered two worki ng
prototypes with limited functionality to the
client. The client is thrilled by the quality of
work delivered. The final delivery is now on
schedule and Agility seems to have saved the
day for the IT company.
AGILITY MYTHS:
As is the case with any emerging trend, there are
many misconceptions about Agility. Some common
myths are
Agility is for small or mid-sized
enterprises only.
False: Agility is not a function of the size of
an enterprise. It demands grace of an expert
ballerina from a tiny mouse as well as a giant
elephant.
Agility means lightweight process, i.e.,
unstructured methods with little or no
documentation.
False:Lightweight signifies the ability of
the process to adapt to changes. Agile
methodologies do insist on minimal
documentation. The emphasis is on
documenting only what is necessary and
not on churning out stacks of irrelevant
documents.
CONCLUSION
Agility in Enterprises is not a modern fad. This is
the defining factor which would shape the
businesses of tomorrow.
The need to be innovative has never been
felt more acutely. This modern era of cut-throat
competition can be best exemplified by Darwins
Theory of Natural Selection, i.e., change or perish.
Those who embrace change and innovate are the
survivors. Others would just fade away. Therefore,
it is prudent for todays businesses to open their
eyes to this reality and start their journey on the
Agile Speedway.
REFERENCES
1. The Future Of Competition: Co-creating
Unique Value With Customers, C. K.
Prahalad and Venkat Ramaswamy,
Harvard Business School Publishing, 2004
2. Agile Software Development Ecosystems,
Alistair Cockburn and Jim Highsmith,
Addison-Wesley, 2004
3. Extreme Programming Explained: Embrace
Change, Kent Beck, Addison-Wesley, 2000
10
4. SCRUM Development Process, Ken
Schwaber, Paper presented at
OOPSLA95, referenced from http:/ /
www.control chaos.com/ ol d-si te/
scrumwp.htm, accessed July 2005
5. Agile Software Development with
SCRUM, Ken Schwaber and Mike Beedle,
Prentice Hall, 2005
6. Scrum Log, Jeff Sutherlands Website at
http:/ / jeffsutherl and.com/ scrum/
index.html, accessed July 2005
7. What is Extreme Programming?, Ron
J ef f r i es Websi t e at ht t p:/ /
www.xprogrammi ng.com/ xpmag/
whatisxp.htm, November 2001
8. Creativity is not Innovation, David Skyrmes
Website at http:/ / dev.skyrme.com/
updates/ u17.htm#creativity, March 1998
11
T
oday, success of any business depends
largely on its ability to adapt quickly to
changing market scenario. Failure to adapt to the
uncertain business environment directly impacts
the Returns On Investments (ROI). It is therefore
important for enterprises to be able to withstand
changes in other words, be agile.
Agility, as a guiding principle, yields
measurable benefits because an agile enterprise
models the business processes and
organizational structure that facilitates
competent ROI. An agile enterprise in effect
translates into cost effectiveness, optimum
organizational efficiency and a comparatively
smaller time-to-market.
EFFECTIVE BUSINESS PROCESS
MANAGEMENT & AGILITY
A business process requires documentation and
is no longer an abstract concept. It is sometimes
prudent to screen technical complexities to
provide prospective customers and partners a
clear understanding of the requirements. The
need for an encoding mechanism that captures
the business processes in an effort to provide
flexibility across, and within, an enterprise has
fuelled the formulation of sound Business
Process Management (BPM) frameworks. BPM
enables enterprises to align their business
requirements with information technology
infrastructure; it bridges the gap between
business and technology landscapes. It helps
develop cross-functional business processes;
defines, automates, and controls business
activities as a whole that incorporates people,
processes and the systems.
BPM also helps enterprises keep track
of intermittent changes or modifications made to
the IT infrastructure without affecting cost,
operational efficiency and speed of response.
To address the various business process
issues and effectively implement them, a BPM
programme begins with identifying the business
process. The next step is to analyze and design
the respective process. People who carry out the
business processes then formulate business
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
Business Process Management:
Facilitating Enterprise Agility
By Akash Saurav Das, Sandeep Gaikwad & Vivek Raut
BPM has taken a giant leap forward in
bridging the gap between business and
technology landscapes
12
process rules domain specific rules that define
business policies, constraints, computations,
reasoning capabilities and various other aspects
of the organization. These business rules form
the foundation of effective decision-making. The
business rules are represented technically by the
IT organizations of enterprises. The business
processes can be interpreted by machines and run
on Business Process Machine Server (BPMS)
while process metrics are maintained for
monitoring and controlling the processes.
Specifications such as Business Process Query
Language (BPQL) have been developed by the
Business Process Management Initiative (BPMI)
to query the process state and process
specifications. The Repository that manages the
deployment of process also comes under the
scope of BPQL.
PERFORMANCE MANAGEMENT
Performance management is the essence of an
agile enterprise that helps maintain efficient
operations of the business processes. BPM also
provides a knowledge base that helps new users,
customers or partners to understand the flow of
business activities within an enterprise. This
provides consistency and time efficiency to
business processes. Used effectively,
performance management and knowledge base
can help cut down the costs and improve
efficiency.
BPM has often proved to be useful in
reducing the average timeline for a project by
making the business process-centric. BPM
templ ates are used i n di fferent market
verticals. The advantage that these templates
offer is manifold.Along with saving a
considerable amount of time, they also reduce
paper processing.and provide immediate access
to critical sections.
With reusability and rapid prototyping
as its hallmarks, BPM helps organizations to
maintain their competitive edge in the market by
streamlining the processes and increasing their
operational efficiency.
INSTITUTIONALIZING BPM
Enterprises now consider BPM as an important
measure to take their businesses to higher levels.
BPM, through automation of many tasks,
enhances process efficiency. Following are a few
benefits of a well-thought out BPM programme:
Shorter revenue cycle will act as an
impetus to enterprise business
Productivity will rise to an optimum level
as fewer people will be needed to perform
the same task
Minimization of error and hence,
improved accuracy
I mproved time management due to
knowledge base and templates and better
communication by use of process
modeling tools
Improved management over performance
and process metrics
Better service to customer hence increased
customer satisfaction.
BPM, however, is not without
challenges. For an enterprise, achieving agility
through BPM means to be process centric and
the transformation from IT-centric to process-
centric is gradual and requires significant
changes to business strategy and practices. The
transition time, however, is critical and holds the
key to success.
STANDARDS FOR BPM
Various industry bodies and institutions have
proposed several standards or languages for
13
BPM. A single standard, however, may not
support all the functionalities of BPM and a
combi nati on of i ndustry standards i s
recommended to take full advantage of BPM.
Fol l owi ng i s an i l l ustrati ve l i st of BPM
standards:
Business Process Modeling Language
(BPML) standard of the bpmi.org group
uses XML specification, which is an open
standard and one of the essential features
for a BPM standard. It supports many
features, open standard languages such
as XML, WSDL specification, various
transaction management concepts and
so on.
One of the other significant standards is
Business Process Execution Language
(BPEL), which is proposed by BEA, IBM,
Microsoft, SAP and Siebel Systems. Most
of the features that are supported by
a BPM standard are also supported by
BPEL.
The XPDL (XML Process Definition
Language), a standard proposed by
Workflow Management Coalition,
follows more minimal features such as
portability and orchestration than other
standards. Orchestration , usually
referred to as workflow, is about finding
an effective way of implementing the
business rules throughout the flow
enabling flows to dynamically adapt their
behavior.
XLANG is a Web-service orchestration
standard proposed by Microsoft. I t
defines how message transfer takes place
between Web services.
While BPML and BPEL are block-
structured standards, BPSS (Business Process
specification Schema) gives us a visual
representation of the designed and implemented
process definitions. The Web Service
Choreography Interface (WSCI) is an interface
definition language whereas XPDL (XML Process
Definition Language) is a workflow definition
language. Any of these standards in isolation
seldom cater to all the required functionalities:
BPEL supports most of the functionality
requirements of BPM but not all and if the
objective is to acquire all the functionalities
required by BPM then a combination of BPEL,
BPSS and BPML may be more suitable.
BPM TOOLS
The use of BPM tools largely depends on the
requirements of enterprises: small enterprises
may use them for modeling their business
14
processes and larger enterprises may find it
useful while creating new applications.
Requirements of a BPM managed
process, which are essential for a BPM tool, are:
Business Process Modeling Language
Graphical environment and specifications,
which define the business process rules
for execution of process
Storage environment for storing the
process and session information.
Tools for capturing manual work and
presenting it
BPM engine for controlling the software
components that are using the described
process for their operations.
Flexibility to face changes that may occur during
modeling or after completion of modeling
Support for open standard language like
XML for communication between Web
services which are going to be modeled.
Many software companies provide
software for defining the business process flow.
A few of the BPM tool vendors are FIleNets
Business Process manager, Fuegos FugoBPM,
Intalios Intalio| n3, Handysofts BizFlow.
CONCLUSION
BPM helps an enterprise to make on-the-fly
changes to its processes and ensure compliance
with the changes that are mandated by market
conditions and the information technology
infrastructure in an enterprise. BPM will play a
significant and enabling role in the future to
help enterprises achieve agility. By breaking
down problems into a number of smaller
manageable problems, the BPM templates
provide reusable solutions. Finally, BPM has
helped position businesses as process-based
enterprises.
REFERENCES
1. The Case For BPM, Accessible from
http:/ / www.ascentn.com/ about_bpm
.html
2. Three Promises of BPM: Agility,
Flexibility, Visibility, Accessible from
http:/ / www.transformmag.com/
d b _ a r e a / a r c h s / 2 0 0 2 / 1 1 /
tfm0211f1.shtml
3. BPM: The next Must Have App,
A ccessi bl e f r om http:/ / www.
cioupdate.com/ reports/ article.php/
11050_3363061_3
4. Web Services, Grid Computing, and
Busi ness Process Management:
Expl oi ti ng Compl ementari ti es for
Business Agility, Proceedings of the IEEE
ICWS, 2004
15
Towards Enterprise Agility
Through Effective Decision
Making
Innovative use of web services and shared data
services in an architecture framework makes for
effective decision making
By SriramAnand & Jai Ganesh
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
O
rganizations operating in fast paced
business environments need to respond
to fast moving windows of opportunities and
to challenges and growth possibilities. There are
short lead times for extracting and presenting
Key Performance Indicators (KPIs) and shorter
lead times for decision making. These business
needs are not in sync with the technological
challenge such as the presence of disparate
enterprise systems (for example, ERP, SCM,
CRM and so on). This situation gets complicated
with the increasing number of mergers and
acquisitions resulting in different business units
within an enterprise having their own data
warehouses. Adding to this is the increasing
number of users i nsi de and outsi de the
enterpri se who need real ti me access to
information.
In such a scenario, an Enterprise Digital
Dashboard (EDD) would improve the lead time
in and quality of decision making by extracting
and generating KPIs from enterprise software
systems. The EDD is an effective tool for
executives to get a top-level view of their
enterprise as well as their closely linked partners.
Decision makers require easy access to data such
as total sales per month, inventory status and a
number of other KPI s. The EDD offers an
enterprise decision maker a single view of the
metrics being monitored in a user-friendly
manner.
The EDD is, in many ways, similar to
an automotive dashboard, which provides the
driver with a single view of the state of the
automobile. Development of an EDD involves
extracting and generating metrics, indicators,
16
sales figures, increasing production of certain
product l i nes, i denti fyi ng l ead ti mes,
inventory levels, and other key organizational
data from the enterprise software systems.
This information resides within applications,
databases, and processes, and must be
extracted and anal yzed to determi ne i ts
impact on a business.
There are two pri mary areas that
represent issues in the rollout of successful
EDDs: retrieval of pertinent data from a
multitude of data sources and interacting with
business systems that may be developed using
heterogeneous technologies.
How can enterprises enhance their
agility through effective decision-making is a
question that currently demands attention.
EDD: VALUE AND CHALLENGES
The EDD, by providing a single view of the
metrics that are being monitored, considerably
improves the efficiency and effectiveness of
decision-making.
An EDD-enabl ed enterpri se i s
typi cal l y characteri zed by faster and
i mproved deci si on-maki ng capabi l i ti es
owing to the availability of real-time access
to i nformati on, KPI of the organi zati ons
business units, and access to KPI s of its key
partners. I n addition, access to notifications
and al erts about cri ti cal events faci l i tate
timely and relevant action.
An EDD also helps improve agility by
enabling enterprises leverage the available data
to make informed decisions and deliver the
right information to the right people at the
right time.
Though benefits abound, implementing
EDD is strewn with challenges. Some of them
are:
Disparate data types
Disparate technologies
Disparate locations
Disparate ownerships
Disparate data
This is put upfront to convey all the key
challenges to the reader. So he will keep this in
mind while reading the architectural challenges.
EDDs are difficult to implement owing
to the complexities involved in combining and
calculating data from disparate enterprise
systems such as SAP, and i2. In addition, there
are associated problems such as duplication of
data that necessitate data synchronization.
Multiple systems in different lines of business
access data in different ways based on their needs
and specific technologies. There are no consistent
practices or techniques in place for the access and
update of data. Apart from this, the same data
element may be stored and accessed in multiple
formats in different databases.
A n enter pr i se dashboar d i s
fundamentally a representation of core business
data in multiple formats. The data elements may
be rolled up to different levels to suit the
requirements of the audience in question.
Therefore, one of the fundamental issues
involved in the development of a dashboard is
to obtain quality data from a variety of sources
without difficulties.
Large enterprise IT groups typically
have a diversified portfolio of systems that has
grown over time and caters to a wide collection
of consumer applications and end users. Though
unstructured growth of applications leads to
multiple monolithic applications that efficiently
deliver core functionality, they fail to exist in
harmony with other applications. Enterprise
dashboards therefore must communicate with
multiple business applications to display the
17
correct information and apply correct rules in
order to display certain data.
ARCHITECTURAL CHALLENGES
Critical data scattered across
geographies is a barrier for effective decision
making (Figure 1). The diversity of the data
sources involved makes management of the data
sources and the centralization of common data
across lines of business and geographies very
important for fulfilling the business
requirements. Following are some of the specific
issues and challenges in this regard:
1. View of data: The scatter of critical data
across multiple databases in various
business and geographies is a serious
issue obstructing a clear view of the data.
For example, customer data if so scattered
impedes identification of key customer
attributes. I ndependent, unmanaged
changes to systems and databases leads
to confusion that in turn results in higher
effort and cost to obtain consolidated
customer information.
1
2. Systems logic: A wide spread of systems
and databases may affect the performance
of business applications owing to complex
business logic. The applications are
burdened with embedded logic associated
with multiple data elements residing in
different databases. Chaos may be the rule
in the absence of a clear mapping between
business processes and the data elements
that are needed to fulfill those processes.
3. Integration costs: Technology and
toolkits available for data access have
D
a
s
h
b
o
a
r
d
D
a
t
a
A
c
c
e
s
s
T
i
e
r
Business
Apps - USA
SCM - Europe
ERP - Asia
Business
Apps - South
America
Legacy
Mainframe -
USA
RDBMS - USA
Legacy-
Europe
SCM - Europe
ERP - Asia
SCM - Asia
CRM - Asia
Oracle
South
America
Data
Synchronization
Legend
Data common across business lines/geographies
Applications in Europe
Applications in Asia
Applications in the U.S.A
Applications in South America
Figure 1: Current state of systems and databases. Source: Infosys Research
18
matured significantly whether they are in
the J2EE space or the Microsoft space.
Depending on the manner in which
specific technologies have evolved in a
given Line of Business (LOB), the data
access techniques may vary between
applications and can result in higher costs
incurred for integration across LOBs.
4. Channels of update: The core business
data in a specific database may be
updated by various means: Direct,
Indirect or by other channels. Data can
either be updated directly through the
business applications dedicated for that
LOB or indirectly upgraded through
synchronization with databases of other
LOBs. It can also be updated through
other channels such as I VR or by a
customer service representative over
telephone or manually.
Multiple channels of data updates can have
a bearing on user experience. For example,
a user may request for a change in personal
information over the phone or IVR and
attempt to lookup the same data online.
Latencies in the update of the data that has
been sent over the phone may result in
incorrect data to be displayed.
5. Resource contention: Heavy loads on
databases are common during a bulk
update. For example, there may be certain
periods of time when customer
enrollment through the submission of
paper forms for some specific financial
offerings may increase. Such a bulk
update might invlove measures to lock
the database front and consequently users
who are making changes to the online
application are likely to experience
inconsistencies.
6. Latencies in data retrieval: The spread of
critical data across multiple databases and
the associated redundancy may cause
addi ti onal l atenci es for certai n
applications. This can happen due to the
bulk update
scenario illustrated above. Such a scenario may
also arise due to overheads associated with data
synchronization. Alternatively, this may happen
when common, redundant data is retrieved
from a database associated with a certain line
of database that also retains line of business
data.
Considering the above challenges to
effecti ve i mpl ementati on of EDD, Web
services are an effective technology to power
EDDs. Web services, by being loosely coupled
and interoperable, enable easy extraction of
appropriate data from enterprise systems and
facilitate executive decision-making. Web
services enable EDD to process enterprise-
wide data to arrive at an appropriate metrics
that can then be displayed as a portal screen.
A high degree of personalization can also be
made possible depending upon the type of
metrics chosen by the decision maker. The
result is a shorter lead-time for decision-
maki ng as ti mel y i nformati on i s made
avai l abl e wi th access to data i n mul ti pl e
sources.
ILLUSTRATIVE BUSINESS SCENARIO
The automotive industry is in the middle of
adversities: global economic slowdown, global
over-capacity, decreasing prices and margins,
consolidation, and so on. Access to critical
information and effective decision-making
therefore are of prime importance. Large
automotive companies operate across
geographies.
19
Consider the case of a multi-billion
dollar automotive company with business units
spread all over the world. Massive consolidation
in the automotive industry and within the company
has resulted in a wide variety of disparate IT assets
residing in different geographies and supporting
different business models.
Seamless sharing of information across
all operations of the automotive company,
however, is necessary to leverage the benefits of
consolidation such as cost reduction and effective
information access. Appropriate alignment
between geographically dispersed business units
and functional groups is required to create a
unified view of sales, dealers, consumers,
products, and services. Currently, each business
unit, functional group, and brand of the company
operates through independent systems,
programs and so on. As a result, there is limited
synergy across the organization, leading to
inefficiencies and lack of coordination.
The automotive company is structured
across geographies as strategic business units
(SBUs). The SBUs are a mix of both legacy as well
as modern systems (for example, ERP, SCM and
CRM). The systems of the company across SBUs
are as follows:
1. North America [Legacy systems
(Mainframes)]
2. Europe [Legacy +SCM]
3. Asia [ERP +SCM +CRM]
4. South America [J ava based + Oracle
RDBMS]
The company wants to offer its CXOs a top-level
view of performance of its SBUs. The KPIs
required are the following:
Revenues by SBU
1. Drill down (break-up by product
categories)
2. Drill down (break-up by brands)
Revenues target vs actual by SBU
categories)
2. Drill down (break-up by cars)
Revenue forecast by SBU
categories)
Sales volumes by SBU
categories)
Production volumes by SBU
1. Drill down (break-up by
manufacturing plants)
Top dealers by SBU
categories)
Profit margins by SBU
categories)
The above scenario illustrates the key
decision making metrices required by the CEO
and the disparate nature of the systems in place
within the organization.
A Web services based EDD architecture
is proposed to provide a clear top-level view to
the executive decision makers of the company.
Proposed Architectural Solution
The key architectural requirements for the
proposed framework include: ability to integrate
data sources in a loosely coupled manner, ability
to provide a unified view of information persistent
across varied data sources, use design patterns
wherever appropriate, buy instead of build use
proven commercial/ open source products/
frameworks instead of building from scratch
(Figure 2, page 21).
20
The architecture consists of two main
tiers:
1. The Data Access tier
2. The Enterprise Dashboard tier:
(The EDD provides an aggregated view
of the enterprise information collected
from varied data sources that are
geographically dispersed).
Data Access Tier: The core Enterprise
Information Integration (EII) functionality is
implemented by the data access tier. The data
access tier will focus on the various issues and
challenges discussed in detail above. While most
conventional data integration solutions result in
a number of touch points between the business
logic and the integration logic, Web services
provide a loosely coupled and extensible solution
wherein different types of data sources can be
integrated with the EDD without requiring many
changes to the existing functionalities. The
solution to the problem of the automotive
company lies in providing a consolidated view
of data across the enterprise by eliminating
multiple data update channels and by providing
a single suite of applications to access/ update
data.
2
Implementing this suite of applications as
services would eliminate any lock-in on protocols
and integrate easily in a heterogeneous
environment. Specific aspects of the new
architecture to address these issues would be as
follows:
Provi de a composi te vi ew of data
tailored to business processes and usage
patterns
3
Develop shared data services that can
retrieve information for a set of related
applications. Each client application uses
a subset of the classes managed by the
data service, but the data service manages
the relationships between the classes and
ensures that each application is aware of
all data changes, regardless of the source
of change
Design service contracts based on the needs
of individual LOBs/ client applications
Provide information on demand (in
response to service requests) by
optimizing performance and caching
heavily accessed data
Enforce data security by authenticating
invocation clients and protecting against
unauthorized data access
Eliminate back door updates by providing
the service layer that guarantees data
consistency across all systems.
Enterprise Dashboard Tier: The
Enterprise Dashboard provides a user interface
and takes care of other non-functional tasks such
as security, internationalization, scalability,
availability and caching. This allows incremental
adoption of the Web services strategy, which is a
big draw for organizations that have a huge IT
infrastructure to migrate.
The specific characteristics of the overall
architecture are as follows:
Web services created for the purpose of
providing functionality in a loosely
coupled, implementation independent
manner. These implementations will
leverage the core business logic in the
existing applications.
A centralized database that maintains
data common to multiple lines of business
and geographies. This will require
rationalization and consensus building of
the data models that satisfy current and
anticipated needs. This database will
become the system of record and the
owner for the common data.
A set of services that manage data access/
update for all databases. These services
21
will manage all data access/ update and
will become the de facto data access layer
for all applications. Transaction
management for complex transactions
that span multiple databases will not be
performed at the service layer. The
services will provide access to multiple
data sources; it will be the responsibility
of the data consumers to manage
heterogeneous transactions.
4
LOB data continues to reside in existing
databases. Depending on the specific line
of business and the problems (or lack
thereof) associated with the business data,
this data will continue to remain in the
existing databases. Physically, the data
may be migrated to one common platform
if it makes sense from a strategic vendor
management or licensing perspective.
However, the important point to note is
that data will be segregated on the basis
of usage by lines of business with the
shared data services layer simply
providing a uniform mechanism of
accessing the data.
Infrastructure functionality consolidated
and implemented as a Web service to
allow additional consumers to leverage
the same rules and components. An
i mportant benefi t i s i n the area of
security, specifically authentication and
access control.
Scalability and availability of various
applications handled in a streamlined
Legend
Figure 2: Web Services based EDD architecture Source: Infosys Research
D
a
t
a
W
e
b
S
e
r
v
i
c
e
s
D
a
s
h
B
o
a
r
d
Functionality
based
Web Services
Functionality
based
Web Services
ERP Web
Services
SCM Web
Services
WSRP
Compliant
Portlets
Business
Apps -USA
SCM - Europe
ERP - Asia
Business Apps -
South America
Legacy
Mainframe
USA
RDBMS - USA
SCM - Europe
ERP - Asia
ERP - Asia
SCM - Asia
CRM - Asia
Oracle
South America
Centralized
Common
Data
Data common across business lines/geographies
Applications in Europe
Applications in Asia
Applications in the U.S.A
Applications in South America
22
manner by using Web services.
Implementing strict service contracts with
specific levels of service decouples the
service consumers from actual service
i mpl ementati ons. Thi s enabl es the
servi ce i mpl ementer to have the
flexibility of deploying service
implementations in the most optimal
manner. Apart from this, Web service
management tools may be used for
service lifecycle management.
Benefits of Web Services
It is important to analyze the actual benefit
gained due to the migration to Web services that
help realize an EDD. This analysis will help in
identification of the factors that may be used for
the calculation of Return On Investments (ROI).
5
The various factors associated with the technical
and business viewpoints are as illustrated
below:
Cost reduction: I n the existing setup, as
individual LOBs manage various aspects,
including infrastructure and common data, each
of them incur these costs in addition to costs
incurred to address customer experience issues
and troubleshoot problems.
With the centralization of common
functionality and data, and the elimination of
multiple redundant data sources and channels
of update, a significant portion of this cost may
be eliminated. There may be higher upfront costs
involved in implementing the Web services, but
the long-term costs related to recurring yearly
expenses should be lower at least as far as the
common data, processes, and functionality are
concerned.
Flexible business applications: Web services
with a robust service contract and SLAs will
allow new applications to be built faster and
cheaper. Thi s wi l l pave the way for
modifications to business process as well as the
ability to meet IT challenges of new business
requirements. Essentially, this will result in one
l ess probl em to sol ve for the CI O. The
streamlined availability of data through the
shared data servi ces wi l l ease the
implementation of new business applications.
Integration across LOBs will be significantly
easier as common data will be shared and
accessed in a standard fashion.
Transparency for LOBs: In the existing model,
applications had to be designed to handle issues
with respect to heterogeneous systems, data
redundancy, and data synchronization. Business
processes also had to be designed to
handle anomalies in synchronization. The
implementation of Web services will completely
insulate LOB applications from redundancies
in data storage and issues with data
synchronization.
Unified Patterns: As discussed earlier, the
dependency on proprietary techniques and
frameworks used for component development in
various LOBs can be eliminated by implementing
Web services. For example, in the case of data
services, this will provide unified data usage
patterns across applications/ LOBs thereby
enabling developers to talk a common language.
The redesign and implementation of shared data
services results in the data being available in
granularity that is based on real business needs.
Consumer applications will not have to retrieve
data in raw format and assemble pieces to create
front-end views.
CONCLUSION
Gaining competitive advantage in a global
business environment means that the managers
should have easy access to information that
facilitates informed decision-making. The
technology adoption trend is shifting to a
23
scenario where the decision makers should be
able to access KPIs of the enterprise using various
devices, accessing KPI s of business units
distributed across the globe.
A Web-services-based EDD solution
has tremendous potential to solve this business
problem by enabling information aggregation
from multiple disparate systems spread across
the enterprise. Web services-based EDD costs
l ess as i t l everages the exi sti ng l egacy
i nvestments. The reference archi tecture
leverages Web services and handles all the
functionalities as desired for an EDD. The
proposed archi tecture i s based on l i ve
experience in designing a Web services based
SOA. The architecture described above provides
the core service-orientation to the IT architecture
of an automotive firm and can be considered as
a baseline architecture for all EDD enterprise
enablement. The architecture enables a true
flexible aggregation of information from the
internal systems of the organization using Web
services, and offers a single point of contact for
decision making information. Further, this
enables existing legacy applications to take part
in the overall business architecture.
Integration solutions from EAI vendors involve
large initial investments. Moreover the EAI
products are not very flexible, do not fully
support incremental investments and are
proprietary. Moreover it is not easy to work
around with EAI systems while integrating with
I T systems of different partners with
heterogeneous systems.
The above problems need to be addressed while
i mpl ementi ng a Web servi ces based EDD
solution. This is because the solution should be
able to interact with various systems, should be
fl exi bl e, shoul d support i ncremental
investments, and should be able to interact with
the systems of the firms partners. Web services
address most of these. Web services support
the data coming from various disparate systems
to have a single view of the data. The following
are some of the benefits that may be obtained in
a retail scenario by implementing an EDD using
Web services:
Web services based EDD allows the
decision makers to have a single unified
view of data thereby enhancing the
quality of decision making
Web services enable the aggregation of
data from the disparate systems of the
automotive firm thereby facilitating easy
data extraction from various databases,
applications and processes. This would
empower the decision maker to make
decisions based on the sales trends and
A Web Services-based EDD solution, when implemented
effectively, enables information aggregation from multiple
disparate systems and helps decision makers access key
performance indices
24
customer preferences in various channels
and forecast future sales across various
channels and also have better inventory
planning.
REFERENCES
1. Data Services for Next-Generation SOAs,
Christopher Keene, Web Services Journal,
December 2004
2. How Do You SOA Enable Your Data
Assets? Jim Green, DM Direct Newsletter,
October 15, 2004
3. 12 Steps to I mplementing A Service
Oriented Architecture, David S.
Linthicum, White paper Grand Central
Communications, October 2004
4. Architecting Data Assets, Jeff Schulman,
Gartner Research, August 2004
5. Ash Parikh, Rajesh Pradhan and Nirav
Shah, Teaming up portals and web
services. Java Pro Magazine (May 2004).
6. Jon Byous, Single Sign-on Simplicity with
SAML. http:/ / java.sun.com/ features/
2002/ 05/ single-signon.html
25
Co-Creating Experiences of
Value with Customers
Building Experience Co-Creation Platforms
enhances value creation and fosters innovation.
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
By Venkat Ramaswamy
I
n an era of ubiquitous connectivity, active,
i nformed, networked, and empowered
customers are challenging the traditional firm-
centric process of value creation that has served
companies so well over the past hundred years.
Prahalad and Ramaswamy (2004) argue that we
are on the cusp of a profound shift in the way
value is created from a firm-centric process to
a co-creation process jointly by the customer and
the company. In a co-creation process, customer
value emerges from the space of interactions
between the customer and the company, and the
quality of customer experiences associated with
those i nteracti ons and thei r outcomes
outcomes that simultaneously generate business
value to the companies that facilitate them
effectively.
The traditional view of value creation and
its dominant logic are shown in Figure 1 overleaf.
This dominant logic of the modern
corporation that has served us so well over the
past hundred years is now being challenged as
never before. For starters, individuals today are
far more informed through the Internet and
connected with each other than ever before. The
mere fact that there are over 1.6 billion
cellphones, not to mention countless ways of
voicing and self-expression, and
communicating with other consumers (e.g., e-
mail, instant messaging, SMS, Blogs with RSS,
etc.), enable individuals to learn about others
experiences with products and services much
more rapidly. Firms were assumed to have more
information and knowledge than individuals.
Individuals now have a new found freedom
that liberates them from being targets to be had
by institutions. As individuals increasingly have
the motivation and the means to take more
control of their experiences, companies can no
longer act autonomously, designing products,
developing production processes, crafting
marketing messages, and controlling sales
channels with little or no interference from
consumers. Customers now seek to exercise their
influence in every part of the business system.
For instance, there are currently over 30 million
blogs, over one-third of which were created in
the first quarter of 2005. Further, over half of
26
the bloggers are adults. Blogs fundamentally
challenge the nature of relationship between the
institution (company) and the individual
(customer). Armed with new tools and
dissatisfied with available choices, individuals
(customers) want to interact with firms, as well
as (customer) communities to co-create value.
The use of interaction as a basis for value creation
is at the crux of the emerging opportunity space.
THE NEW OPPORTUNITY SPACE:
ENABLING EXPERIENCE ENVIRONMENTS
Consider the case of Apple. Through its iTunes
service, customers have downloaded over 350
million songs of their choice, after listening to a
sample of the song, thereby escaping the
tyranny of the CD (although individuals still can
downl oad an enti re CD i f they so wi sh).
Individuals including musicians can also
publish and share their own playlists using the
iMix tool that Apple provides. The community
of musi c l overs i s engaged i n hel pi ng
i ndi vi dual s di scover new musi c. The
downloaded music can be transferred to the
Apple iPod over 5 million iPods were sold in
the first quarter of 2005 alone. The success of
the iPod lies in the fact that Apple understood
and focused on the user experience that
results from user interaction with the iPod.
Working backwards from the user experience,
Apple designed the interface right down to
the scroll wheel to facilitate a compelling
experi ence envi ronment of accessi ng and
listening to music. Besides the physically cool
design, this meant paying a lot of attention to
the underlying software according to Steve
Jobs the software is the user experience. In
other words, the software enables individuals
to scroll through their library quickly, construct
playlists on the go, or simply play user-defined
playlists. Moreover, at the Apple stores (which
as of early 2005 had over 50 million customer
visits; over $1 billion in retail sales; and over $40
million in profit), individuals can learn about
how to actually get music into the iPod (from
their own music collections), download songs
from i Tunes, and get answers to si mpl e
questions such as how do I get music into my
i Pod?. The Appl e store i s a l earni ng
envi ronment, besi des bei ng a sal es
environment. Individuals interactions with
knowledgeable people at the genius bar
(including consumers from Apple user groups)
supports the consumers learning experience.
Thus, as shown in Figure 2, value to
me as an individual consumer lies in the human
experience associated with outcomes of processes
of interactions with Apples iPod, the process of
Traditional View of Value
Value = Fn (Products & Services)
Suppliers The Firm
Marketing
Channels
SCM ERP CRM
Passive
Customers
Firm-centric products and services
have been the basis for value creation
The Dominant Logic of Value Creation
1. Value creation is associated with products and
services
2. Firms have more information and knowledge than
customers
3. The firm unilaterally defines and creates value for the
customer through its activities
4. Value is exchanged with customers who represent
passive demand for the firm's offerings
Figure 1:
Source:
Traditional View of Value Creation
Center for Experience Co-Creation, Ross School of
Business, University of Michigan
27
downloading songs from iTunes, and/ or
interacting with Apple employees as well as the
user community. As every experience is
contextual, the challenge for companies like
Apple is to build the capabilities that allow
individual customers to interact with customer
communities, as well as an extended network of
companies, to co-create their own experiences of
value. At the heart of the new value creation
system, are experience environments that go
beyond product and service offerings.
An experience environment (which can
be anywhere in the business system) is centered
on individual-centric interactions with the
companys products, processes, and people, as
well as customer communities. These interactions
are where the customer experience is, and what
the company must deeply understand to design
the technology platforms and information
infrastructure to support compelling experience
environments. This is a profound transformation.
I t challenges the very heart of managerial
capitalism as we have known it over the past 100
years: that the role of the firm is to organize its
activities around creating goods and services for
customers. No longer can any company
unilaterally create value for the customer through
its marketed offerings. Rather, companies must
learn to engage customers in a process of co-
creating value, based on the customers view of
value and not the companys.
Consider a patient with a cardiac
pacemaker that monitors and manages his
heart rhythm and performance, a valuable
benefit. However, this patients comfort level
would increase substantially if someone or
something monitored his heart remotely, and
alerted him and his doctor simultaneously of
any devi ati ons from a predetermi ned
bandwidth of performance, relevant to his
condition. Doctor and patient together could
decide on the remedial response. This scenario
gets more complicated when the patient travels
far from home. A mere alert will not suffice.
The patient needs directions to the best nearby
hospital, and the attending physician needs
Value = Co-Created Experience of Interactions and Outcomes
Consumer
Communities
Nodal
Firm
Nodal
Firm
Nodal
Firm
Nodal
Firm
Network of Firms:
Access to Competence
Customer Communities:
Access to Competence
EMPLOYEES
PROCESSES
CUSTOMERS PRODUCTS
Experience
Environment
Experience Co-Creation
Figure 2: New value creation system Source: Center for Experience Co-Creation,
Ross School of Business, University of Michigan
28
access to the patients medical history. How do
the two doctorshis primary care provider
back home and the physician on call at the out-
of-town hospitalcoordinate their diagnosis
and treatment? Should he call his spouse? How
can he recognize and assess the risks and
devel op an approach to compl i ance and
cooperation with these medical professionals?
The doctors, the facilities and services, and the
pacemaker are all part of a network centered
on the patient and his well-being, as shown in
Figure 3 above. Compani es are al ready
i nstal l i ng el ements of these network
capabilities. Consider Medtronic, Inc., a world
leader in cardiac rhythm management that
seeks to offer lifelong solutions for patients
with chronic heart disease. It has developed a
system of virtual office visits that enables
physicians to check patients implanted cardiac
devices via the Internet. With the Medtronic
CareLink Monitor, the patient can collect data
by holding a small antenna over his implanted
device. The data is captured by the antenna,
downloaded by the monitor, and transmitted
by a standard telephone line to the Medtronic
CareLink Network. On a dedicated secure Web
site, physicians can review patient data and
patients can check on their own conditions
but no one elsesand grant access to family
members or other caregivers.
Medtronics CareLink system goes
beyond the cardiac device itself and unleashes
opportunities for an expanding range of value
creation activities. For example, each persons
heart responds to sti mul ati on sl i ghtl y
differently, and the response can change over
time. I n the future, doctors will be able to
respond to such changes by adjusting the
patients pacemaker remotely. Furthermore,
Medtronics technology platform can support a
wide range of devices and remote monitoring/
di agnosti c systems, potenti al l y used for
monitoring blood sugar readings, brain activity,
bl ood pressure, and other i mportant
physiological measures.
I believe that this pacemaker story is
a prototype of the emerging process of value
creation. The patients interactions with the
doctor, the family, and the ER at the out-of-
town hospital affect the quality of the patients
overall experience. The meaning of value itself
changes from the physi cal product, the
pacemaker, to the co-creation experience of a
specific patient. This co-creation experience
originates in the patients interactions. And the
quality of this experience determines the value
that is created. The goal then is to build the
underl yi ng technol ogy pl atforms and the
i nfrastructure to support a portfol i o of
experi ence envi ronments that ari se from
different experience scenarios as shown in
Figure 4 overleaf.
The value of patient outcomes differs
according to each scenario (not to mention by
patient as well). Consider the context of a crisis
out of town. It is important for Medtronic to
understand deeply the nature of the interaction
events at a granular level. Each experience
Primary
doctor
Patients with
similar condition
Medical
specialists
Scan and
diagnostics
clinic
Doctor on call at
out-of-town hospital
Emergency
services
Pacemaker
manufacturer
Patient
Figure 3:
Source: Center for Experience Co-Creation,
Doctor-patient network
29
scenario in effect can activate multiple experience
environments. The challenge is to identify a
core set of experience environments as shown
below, and build technology platforms and event-
centric information infrastructures to support a
portfolio of experience environments.
Compani es must l earn to bui l d
platforms that enable experience co-creation
processes across the portfolio of experience
environments (i.e., experience co-creation
platforms). In this view, IT platforms become
a strategic enabler of experience co-creation
processes. However, this view forces companies
not to be focused on product specifications and
features that hardwire the process of customer
experience. (Product quality is still critically
important. It is a necessary but not a sufficient
condition for co-creating experiences). Rather,
experience co-creation platforms are about
creating the preconditions to accommodate a
wide variation in individualized experiences
that are contextual and granular. A much deeper
understanding of the experience scenarios of
consumers i s cal l ed for. Thi s depth of
understanding is impossible without active
customer involvement and dialogue. Second,
the experience environments are not just about
hardware; the fl exi bi l i ty for a vari ety of
Patient Experience Scenarios
Primary
doctor
Patients with
similar condition
Medical
specialists
Scan and
diagnostics
clinic
Doctor on call at
Emergency
services
Pacemaker
Patient
Primary
doctor
Patients with
similar condition
Medical
specialists
Scan and
diagnostics
clinic
Doctor on call at
Emergency
services
Pacemaker
Patient
Primary
doctor
Patients with
similar condition
Medical
specialists
Scan and
diagnostics
clinic
Doctor on call at
Emergency
services
Pacemaker
Patient
Primary
doctor
Patients with
similar condition
Medical
specialists
Scan and
diagnostics
clinic
Doctor on call at
Emergency
services
Pacemaker
Patient
1
Crisis out of town
I'm going on a trip, but I'd like to know
whom to turn to once I'm there
I'm a little uneasy and would like to be
checked out remotely by my primary doctor What do you do when you have a similar problem?
1
2
3
4
2
3
4
1
2 3
1
2
Figure 4: Patient experience scenarios Source: Center for Experience Co-Creation,
30
experiences derives from sophisticated use of
software. A deep and i magi nati ve
understanding of the enabling technologies is a
must. Thi rd, i ndi vi dual s engage i n an
experience co-creation process when they
interface with an experience environment,
interact in the context of an event, and assimilate
experience outcomes. These call for new levels
of transparency and access from the customers
perspecti ve, as wel l as the companys
perspective.
THE EXPERIENCE CO-CREATION PROCESS
Consider the environment of tracking the
building of my custom houseboat with Sumerset,
one of the largest houseboat manufacturers in the
world, in Kentucky, USA. This is how a typical
customer interaction might work. I as a customer
can access the manufacturing plant and track the
progress of my boat. Let us assume that I get a
new idea - such as moving the dining table by 4 ft.
The engineers can discuss with me the pros and
cons of doing that. We can make joint decisions
about the changes through the principle of
informed choice, recognizing the cost and quality
and safety implications of the choices made. Of
course, Sumerset can say, that beyond a certain
level of risk, they will not participate in the process.
Sumerset can also introduce me to the community
of houseboat users and I can engage in a dialogue
with them. I can evaluate my choices as I go along,
as well as learn about the possible uses of a
houseboat that I could not have imagined.
The co-creati on process gi ves the
customer a greater level of knowledge and
expertise about houseboats, and with it a
greater degree of self-esteem. Dialoguing with
Sumersets empl oyees and tracki ng the
progress of the boat along the factory floor
creates a sense of emotional bonding with the
product and the company (an outcome of value
to the customer). Sumersets transparency and
wi l l i ngness to di al ogue enhances the
customers readiness to trust the company and
believe in the quality of its product. Access to
the communi ty of Sumerset customers
increases the consumers enjoyment of the
houseboat. Thus, the basis of value for the
customer shifts from a physical product (with
or without ancillary services) to the total co-
creati on experi ence, whi ch i ncl udes co-
designing as well as all the other interactions
among the consumer, the company, and, the
larger community of houseboaters. Thus, the
co-created experience outcomes depends on
the nature and level of access to the companys
employees and extended community, as well
as the level of transparency of all parties.
As the Sumerset example illustrates,
individuals must be able to co-construct unique
value for themselves through customer-network
interactions that facilitate contextualized
experience outcomes through dialogue, access,
A Portfolio of 'Core' Experience Environments
PATIENT PATIENT PATIENT PATIENT
Primary
Doctor
Remote
Doctor
Diagnostic
Clinic
Emergency
Services
Medtronic
Medical
Support
Medtronic
Medical
Support
Medtronic
Medical
Support
Medtronic
Emergency
Call Center
TECHNOLOGY PLATFORMS
AND EVENT-CENTRIC
INFORMATION INFRASTRUCTURE
Figure 5:
Patient 'core' experience environment
31
risk management, and transparency (or DART
for short) the basic building blocks of co-
creation:
Dialogue encourages not just knowledge
sharing, but, even more importantly,
shared understanding between
companies and customers. It also gives
individuals more opportunity to interject
their view of outcomes of value into the
value creation process.
Access to knowledge, tools, and expertise
helps individuals construct their own
experience outcomes. Access also
challenges the notion that ownership is
the only way for the consumer to
experience value. By focusing on access
to experiences at multiple points of
interaction, as opposed to simply
ownership of products, companies can
broaden their view of business
opportunities.
Risk management assumes that if
consumers become co-creators of value
with companies, they will demand more
information about potential risks of goods
and services; but they may also have to
bear more responsibility for dealing with
those risks.
Transparency of information in
interaction processes is necessary for
individuals to participate effectively in co-
creation mode and engender trust
between institutions and individuals.
DART must be enabled by technical and social
infrastructures and platforms that enable
consumers to co-construct experiences they
value and Sumerset to generate business value.
Sumerset and its suppliers can learn more about
consumers and get new ideas for design,
engineering, and manufacturing. Sumersets
empl oyeesfrom desi gn engi neers to
carpenterscan more deepl y understand
consumer aspirations, desires, motivations,
behaviors, and agreeable trade-offs regarding
features and functions. Through continuous
dialogue, employees can relate their efforts to
individual consumers. The company can reduce
uncertainty in capital commitments and even
spot and eliminate sources of environmental
risk.
Experience environments are
characterized by the ability to accommodate a
wide range of context-specific experiences of
heterogeneous individuals. These experiences, by
definition, cannot be identified in detail a priori.
The focus in innovating experience
environments, therefore, is different from the
traditional focus on innovating products and
services. We can develop a broad specification
based on our discussion so far. At a minimum,
the experience environments must accommodate
a heterogeneous group of consumers- from the
very sophisticated and active to the very
unsophisticated and passive; must engage the
customer emotionally and intellectually, must
accommodate the involvement of customer
communities, must explicitly recognize the social
and the technological aspects of experience, must
enable an integrated experience for consumers
through the creative integration of products,
employees, communities, and the various
customer interfaces in interactions, including
multiple channels and modalities that facilitate
access.
This specification for experience
environments may appear daunting, especially
when it is juxtaposed with the current
preoccupations of managers focused on
improving the innovative capacity and efficiency
of their organizations, through reduced cycle
time for product development, making process
32
improvements, and increasing product variety.
In contrast, innovating experience environments
means not only focusing on experiences but
allowing customers to engage in a co-creation
process of co-constructing those experiences
through interactions in the experience
environment.
EXPERIENCE CO-CREATION INSIDE THE
COMPANY AND ITS NETWORK
The same DART building blocks also facilitate
the i nteracti on from the companys
perspective. One of the major challenges that
companies will face is that in some experience
scenarios, the resources of one or more entities
in the network which the company does not
own, may have a large role in co-shaping the
customer experience. For example, in the out
of town experience scenario, the patients
interactions with the emergency room (ER) at
the out-of-town hospital affect the quality of
the patients overall experience. What this
means is that some companies like Medtronic
may have to become nodal companies in the
network that provi de the i ntel l ectual
leadership, and the protocols and disciplines
for governing partners and people in the
network. I n the worl d of experi ence co-
creation, every employee who has the ability
to directly influence the consumer experience,
and facilitate the co-creation of value, must be
regarded as a line manager. Companies must
build information infrastructures that allow
line managers to experience the business as
consumers do, thereby achieving a new level
of personal effectiveness for human enablers
of experiences in the network. Without event-
centric information infrastructures in the
network, it is practically impossible to govern
the quality of experiences.
Now imagine yourself as a manager
in the ER. Managing the co-creation experience
demands a new capability: the ability for
managers to rel ate to consumer (pati ent)
interactions with the company (ER unit in the
hospital). This requires that managers have the
capacity to experience and understand the
business as customers do, and not merely as
an abstraction of numbers and charts. Consider
a typical emergency room in a busy downtown
hospi tal . I ts not uncommon for about 40
percent of a hospitals patients to enter the
system through the emergency room. From a
managerial perspective, its critical to be very
efficient in moving patients through the ER as
fast as possible without compromising the level
of care. But in an emergency room, demand is
random and unpredi ctabl e. There are no
predetermined sequences of procedures that
can be followed. The need depends on the
nature of the problem; a gunshot wound, a
heart attack, and a broken arm are all different.
But they all require the services of multiple
doctors, medical staff, and technicians, as well
as the physi cal movement of the pati ent
through various stages of examination, testing,
and treatment.
Real-life emergency rooms look as
crazy and chaotic as they do in TV medical
dramas. The progress of the patient, the status
of various tests, and the availability of rooms
are tracked on bits of paper, in PCs, and on
whiteboards posted in the clinic. Often the
pati ent i s too si ck to tal k, and fri ends or
relatives anxiously wait outside, demanding
information and answers from harried hospital
employees.
As a manager, how do you know what
is happening at any given point in time?
Historical analysis of two-day-old data will not
33
help you solve problems as it is happening, much
less improve the quality of current patient
experience. Improving patient care, on a real time
basis requires managers to answer specific
questions: Are patients waiting too long at a
given station? Do the doctors, nurses, and
technicians have access to the resources they
need? Are ER capacities being fully utilized? Is
there a big queue for X-ray?
Further, how do managers at different
levelsfrom the chief nurse, the head of the
emergency services unit, to a VP of the hospital,
experience the business as patients, patients
families, technicians, doctors, and the interns
experience it? Is the patient waiting for more than
45 minutes of service? How do we begin to
understand the patients co-creation experience
with the hospitals experience network?
And how do you as a line manager
respond in real time? For instance, as a head
nurse, how do you respond when two night-shift
nurses call in sickjust as a massive fire across
town fills the ER with victims of smoke inhalation
and burns? And suppose you are the head of the
emergency unit, can you provide the level of
required staffing without compromising the
quality of care for other existing patients in the
hospital?
Meanwhile, a VP in the hospital, a
couple of steps removed from the ER, has some
questions of his own. What is the average waiting
time for a patient to receive care? Where are the
bottlenecks? On arrival and registration? Waiting
for a doctor, for a room, for tests? And who is
paying for the care? Are insurance reimbursement
rates rising or falling? Is the ER a profitable center
for the hospital, or is it incurring chronic losses?
Why?
The goal of the information system is
not to substitute the nurse, technician, or the
doctor, but to provide them with a system that
aids the amplification of weak signals based on
the real -ti me experi ences of consumers
(patients). This means the construction of
information in the context of a specific co-
creation experience. A managers personal
effectiveness in such a situation depends on his
capacity to generate hypotheses around the
problems encountered by a patient and develop
actions in real-time.
But how can managers of large and
mid-sized companies achieve this kind of
visceral understanding of the business as
experi enced by customers? How can l i ne
managers feel and share the consumers
concerns, desires, and aspirations? How can
they make their experience of the business, on a
real-time, continuous basis, approximate to the
experience of consumers?
Building Event-centric Information
Infrastructures
An event-centric information system must start
with eventsa patient arrival, a registration
process, a visit to a X-ray roomas well as their
metricstime spent in the waiting room, time
required to make a diagnosis, and overall length
of stay. This event-centric information must be
available to the line manager in real time and
within its context of space and time. For example:
Patients are waiting forty-five minutes for X-
rays on Wednesday mornings, or Bed
assignments are taking longer than thirty
minutes.
As a manager, I should be able to
construct the experi ence from di fferent
perspectives, such as an overloaded doctor, an
anxious patient or a beleaguered technician. I
should also be able to connect with others
involved in providing services within the
system and create appropriate practices by
col l aborati ng i n real ti me to sol ve new
34
problems. Just as it is critical for customers to
be able to interact with communities of other
customers, managers should also be able to
communicate with practice communities to co-
construct new knowledge and co-create better
customer experiences.
As a manager, I should be able to experience
customer-company interactions as it is
happening, and understand and evaluate its
implications. Real-time information without
context has little value for me as a manager.
Learning from experiences requires that the
event-centric information system enables me to
reconstruct events. Real-time intervention is
different from the analysis of specific experiences
after the fact to search for patterns, formulate
hypotheses, and codify the learning. For
managers to become co-creators, they should
have the capability for real time intervention as
well as after the fact analysis.
Such capabilities must be available to every
manager in the ER. That includes all the
employees involved in creating a good customer
(patient) experience, including doctors, nurses,
lab technicians, the clerk at the registration
counter, and the ward assistants who transport
patients and deliver supplies.
In todays ER, do line managers have access to
all of the capabilities weve suggested? Usually
they do notnot for technological reasons, but
because our management systems have not yet
caught up with the changing locus of value
creationthe various points of customer-
company interactions. The question is: How do
we get the managerial equivalent of embedded
intelligence, as when a smart product, like the
pacemaker, interacts with the consumer? Thus,
companies must facilitate managerial learning
and action, through co-evolution with customer
experiences, at all points of company-consumer
interaction.
Consider the digital hospital at the
Hackensack University Medical Center in
Hackensack, New Jersey.
1
Doctors can tap an
internal Web site to examine X-rays from a
computer anywhere inside and outside the
hospital, and even control a life-size robot (a
digital doc with the typical white lab coat and
stethoscope) from their laptops at home. They can
direct this digital doc into hospital rooms and
use two-way video to discuss patients
conditions. Nurses can use a PC that rolls around
on an IV-like stand and log into patient electronic
records through a wireless connection, to review
vital signs temperature, heart rate etc
entered into the computer by a nurses aide
earlier. Nurses can pull up medication orders,
check accuracy of medications and dosage levels,
Managerially experiencing
the consumer experience;
Managerial heterogeneity
Ability to access, interpret,
and experiment within
the event-centric system
Building and maintaining internal
systems and processes;
Conventional innovation and
efficiency mindset
Managerial Information Infrastructure Capabilities
New Demands
from Experience
Co-Creation with
Customer
Focus on
Line Managers
The IT Interaction
Interface in Experience
Environments
The Reality of IT
Heterogeneous consumer
experiences; Contextual insights;
Network collaboration for
Co-Creation; Rapid Resource
Reconfiguration
Figure 6:
Line manager-IT interface
35
and even interact with other sources of medical
expertise to learn about patient therapies. They
can spend more time on care-giving now and
enhance the quality of the patient experience.
Previously, nurses were always on the phone
with the pharmacies, trying to get medication
refills, or with doctors, trying to decipher their
handwriting. Now the system ensures that the
pharmacy gets drugs to nurses on schedule and
that nurses can access almost every piece of
information they need, from what insurance plan
a patient is on to what tests they have had in the
hospital. Patients can use TVs in their rooms to
access information about their medical
conditions. While Hackensack is reporting
increased productivity, lower costs, and
simultaneously better patient outcomes, a recent
high-profile study published in the Journal of the
American Medical Association in early March
2005 showed that a tech system used by the
University of Pennsylvanias hospital to prescribe
drugs created new ways to make errors. In one
example, it scattered patient data and drug-
ordering forms over so many different computer
windows that it increased the likelihood of
doctors ordering the wrong medications. The
point here is that technology must enable better
physician, nurse, and patient experiences. In
other words, the experience environments must
be designed for effective co-creation of
experience outcomes for various participants and
stakeholders in the network.
THE NEW ROLE OF THE CIO
CIOs have a new role in building information
infrastructure capabilities for the experience co-
creation organization. In doing so, however, they
must confront the reality of IT and challenges in
the Line manager-I T interface in enabling
experience environments, as shown in Figure 6
on page 34.
IT infrastructure matters because it
communicates the reality of consumers and their
experiences to line managers. The relationship
is like that between a topographical map and the
actual terrain. The more accurately the map
reflects the terrain, the easier for travelers to find
their way. The more complex the terrain, the
more detailed and accurate the map. Given the
demands of the real-time enterprise, the map
must correspond to the terrain as it is changing.
Most information systems force managers to use
old maps, since they provide only historical
analysis of data, or provide inappropriate maps
that work only with a fixed set of predetermined
analytical tools. Such systems complicate
exploration and navigation. Managers must
demand event-centri c i nf ormati on
infrastructures that can can support experience
environments and foster experience innovation.
The goal of the line manager (e.g., nurse,
physician etc) is to managerially experience the
customer experience in real time with zero
The Strategic Role of IT:
Enabling Experience Co-Creation Processes
Global Network of Firms
and Global Communication of Individuals
As a Source of Competence
Technology Platforms
& Event-centric
Information Infrastructure
P
o
r
t
f
o
l
i
o
o
f
'
C
o
r
e
'
Experien
c
e
E
n
v
i
r
o
n
m
e
n
t
Experience Co-Creation Processes
Figure 7:
IT enabled Experience co-creation
36
latency. As a care giver, I want to experience the
business as the patient does, and act when the
patient is having a problem. Thus, for companies
to migrate towards experience co-creation, its
technology platforms and event-centric
information infrastructures must support critical
experience co-creation processes underlying the
portfolio of core experience environments as
shown in Figure 7 on page 35.
In this emerging new future of IT, the
new role of the CIO is elevated to supporting
experience co-creation processes that facilitate the
companys role of co-creating unique value with
its customers. To compete successfully in the
future as it is becoming, companies must build
new strategic capital the capacity to create value
thru experience co-creation, rather than the
dominant logic of firm and product-centric value
creation that has indeed served us so well over
the past hundred years. The latter is becoming
inadequate (witness the declining margins,
commoditization, erosion of traditional
competitive advantage in industries across the
globe) in an era of technology and market
convergence, deregulation and privatization,
globalization, and connected, informed, and
empowered customers with the motivation and
tools to actively engage and insert themselves in
the value creation process.
To be future proof, companies must
build experience co-creation platforms and event-
centric information infrastructures that enable
experience environments, and in turn,
compelling customer experiences that generate
the new revenue enhancing opportunities. For
companies to sustain profitable growth, they
must continuously generate new knowledge of
customer experiences and identify and enable
new value creation opportunities with customers.
Welcome to the next paradigm of experience co-
creation!
ABOUT THE AUTHOR
Prof. Venkat Ramaswamy is one of the two founders
of the Experience Co-Creation Partnership. He is
also the Michael R. and Mary Kay Hallman Fellow
of Electronic Business and Professor of Marketing
at the Ross School of Business, University of
Michigan. He is the co-author of the acclaimed book
The Future of Competition: Co-creating Unique
Value with Customers (co-authored with C. K.
Prahalad).
Venkat is a globally recognized thought leader, idea
practitioner, and an eclectic scholar with wide-
ranging interests in innovation, strategy, marketing,
branding, IT, operations and thehuman sideof the
organization. He is a prolific author of numerous
articles, and a frequent speaker at conferences all
around the world on topics such as innovation,
customer experience, or valuecreation, or industry
focused topics
37
O
ver the years, the Customer Information
System (CIS) projects at utilities have
developed a reputation for being disruptive to
business, very expensive and behind schedule.
While there have been several successes, the
large number of failures and issues have created
a strong case for devising an alternative to large
CIS projects. Utilities are looking for ways to
take smaller, cost-effective steps at appropriate
points in time instead of an expensive, high-risk
project.
Also, there are a number of lurking
external business drivers that can strengthen the
case for a CIS project, as well as internal drivers
that are often difficult to gauge. The question is
when is the time right to work upon the
limitations of an ageing CIS? When do drivers
become important enough to warrant action?
Given that CIS is the mission critical
cash register for utility companies, the current
complex situation merits a closer examination.
A structured solution would improve the
agi l i ty of CI S wi thout maki ng huge
investments. The complex and pertinent scope
and priority challenges facing todays CIS can
be addressed by use of a strategic assessment
framework.
CIS INITIATIVES: PAST AND PRESENT
Over the last decade or so, the utility sectors
experience with CIS projects has been unpleasant,
to put it mildly.
Many utility CIS were installed during
the late 1990s to overcome the Y2K limitations in
older systems. With attention focused on back-
office processes, user interfaces for call and billing
centers took a back seat. Older business processes
were often duplicated from a legacy of
regulation, lower wages and low worker
turnover.
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
Enhancing the Agility for
Customer Information Systems
in Utilities
By Ananth Chandramouli, Clifton L Muhammad & Vivek
An extremely critical part of the service delivery
value chain in utilities,CIS projects need to be
more predictable.
38
Costs and higher cost pressures,
opportunities exist to extract significant
additional value from legacy CIS. In fact, with
increasing costs of skills, navigating the current
user interfaces are often cumbersome and time
consuming. Training costs are high and users
are forced to possess broader system knowledge
for most business functions. System
modifications are time consuming and costly and
limit the scope for business changes and process
improvements.
For most utilities, replacing a CIS is a
decision fraught with huge complexities and
enormous cost ramifications. The complexities
come from many directions but probably the
biggest ones stem from the need for
organizational transformation and thus the clear
imperative to look at it from strategy down to
the operational nitty-gritty. In terms of cost, the
end-to-end cost for CIS replacement is often
quoted in industry circles at about US$35-40 per
customer. The fancier ones (or the poorly
managed ones!) cost even more.
A CIS project is typically associated
with some amount of business disruption in
revenue and customer service, so much so that it
is often considered perfectly normal to have a
few months of lowered performance after
implementation. Erroneous or delayed bills,
longer call handling times and uncollected
revenues are some of the commonly encountered
post-implementation issues.
Typically, major CIS implementations
or replacements take two to four years. Some take
even longer. The long duration of the project
makes them susceptible to vagaries of time
changing business requirements and preferences,
emergence or fading out of technologies, changed
players and expectations, changing market
imperatives and competitive landscape and so
on. It is then no surprise that there have not been
many large CIS replacements in the last few
years
1
.
Technology Drivers
There are a number of technology issues that the
utilities are facing with their CIS. Following are
a few of them:
Service Level Adherence: Ad hoc enhancements
made to some CIS systems have resulted in
inflexible and brittle systems with increased
system down time. Also, data integrity issues
arising out of changes made to modules
independently have affected end users.
Application Enhancement & Maintenance:
Absence of standards to clearly demarcate
presentation logic, business logic, and the data
logic have led to increased time-to-market and
higher cost for executing business change
requests, increased time for impact assessment
and testing while giving room for redundant
changes across modules.
Diminishing Vendor Support: Some of the CIS
systems that have been developed in older client/
server and legacy technologies do not have
adequate support from the product vendors.
There is therefore a higher business risk
associated with continuing with such
technologies. Lack of support also translates into
High business risk of continuing with
such unsupported technologies
Hesitation to enhance systems due to lack
of proper support personnel
High cost of specialist resources
Leveraging New Technologies: Many CI S
applications have become increasingly rigid and
are not amenable to be integrated with newer
technologies. This has resulted in
An opportunity loss to provide more user-
friendly features and functionality, some
directly to the end customers
39
Value add from newer IT systems not
being realized as they are not fully
integrated with CIS.
Business Drivers
External business drivers, which impact the
performance of a CIS, are generally beyond the
control of internal management as they relate to
regulatory and public expectations.
One of the most important external
business drivers is the government regulation
that significantly impacts all operations of a
utility including the CIS. Two examples include
the utilitys obligation to provide service of last
resort and territory limitations. De-regulation of
these obligations impacts system capacity
requirements while regulatory changes that
relate to customer processes also change the
performance expectations of a CIS.
External business drivers also include
the competition and choice of energy sources: A
customer can choose between electricity, gas, coal
and oil for heat.
A number of internal business drivers
including maintenance costs, flexibility and
system performance have an impact on the costs
for CIS operations and system support. These
also should be taken into account while planning
for a CIS project.
Case for Enhancing the Agility of CIS
The challenge before a CIS owner is to select an
enhancement scope that provides the best return
for system stakeholders. The need for improving
a CI S seldom justifies a complete system
replacement; piecemeal enhancements may be
more easily justified at the altar of larger
benefits of a comprehensive solution.
The scope of a CIS enhancement can
include several system architectural and business
process components. Major system components
include a backend, a presentation layer and (in
some cases) a business services layer of which
the back-end demands the highest investment,
sometimes close to 90 percent of the total.
Changes in the presentation and business service
layers, however, contribute to significant
business benefits.
The performance measures that matter
relate to the overall performance of the utility.
Because the CIS directly impacts a utilitys
customer, the strategy and values of the
organization must determine the type and
significance of each CIS performance metric.
Performance metrics can relate to two categories:
first, value delivered to the customer and the
second the cost for delivering that value.
The value accrued to the customer will
vary but is related to the cost borne by the end
customer for the services received. While cost
to the customer include time, effort, and a
premium on quality of service, customer value
measures i ncl udes cal l handl e ti me, fi rst
contact resolutions rate, percentage of calls
answered within a time period, call volume and
so on which indicate the customers perceived
cost.
The cost for delivering customer value
can be quantified and broken down into
measurable components. Some of these measures
are direct labor, service charges, overhead, net
write-offs, and credit cost per customer which
total to the amount spent for customer service.
ACHIEVING CIS AGILITY
Achieving CIS Agility may appear extremely
difficult and even impossible at times, but it is
possible and absolutely essential for a successful
and cost-effective solution. It requires a holistic
approach that encompasses the business process
view, the user-system interaction (or user
experience) view and the technical architecture
40
view of the project. These three diverse views of
the CIS have to come together to present a
complete picture of the needs and requirements
of all stakeholders and to ensure development
of synergy across these tracks of the CIS project.
A better understanding of the three core views
of the project helps in achieving this synergy
when combined with good project and program
management tenets.
Business Process View
The business process view of the project is the view
that concerns the Customer Service (CS) business
unit. This is a large and complex unit that has
significant front-office (customer contact) and back-
office operations including billing and field services.
CS brings in all or most of the revenue of the utility
and comprises many critical business processes. The
CS unit is focused on ensuring the best-of-the-breed
business processes and policies.
This view of the world, often the hardest
to depict and improve upon, is very important
for the project to have a significant impact on the
business. This requires a sound methodology of
business process modeling and business process
analysis combined with a deep understanding of
a utilitys customer service. The main activities
in this track include:
As-is process modeling
Process Analysis
To-be process modeling
The as-is process modeling develops a common
view of the current customer service operations
the processes, their triggers, the activities for
each of the processes and so on. The process
analysis step analyses the as-is processes to
explore the potential for process improvement
through process re-engineering leading to the
creation of an improved to-be process. Making
the to-be process more effective involves various
tasks such as:
1. Application of technology, including
process automation, computer-telephony
integration, use of voice / speech technologies
in call handling, adoption of wireless
technologies for mobile workers, and so on
2. Adoption of alternative process
practices from other organizations or industries
3.Organizational restructuring, often
essential for higher agility, and to drive changes
in a more effective manner.
Consider a typical core billing process
(Figure 1). The as-is process flow presents several
possibilities for improvement:
1. Can some or all of the meter reading
be obtained through Automated Meter Reading
(AMR)? What specific meter readings should be
automated using what AMR technology?
2. Is meter reading route and schedule
better managed through an automated algorithm
for optimal use of resources?
3.What are the possibilities of
automation of manually handled exceptions? Can
a rules-engine be designed to continually reduce
the exceptions as exception patterns are analyzed
and automated?
4. What exceptions are raised due to
gaps in process between groups of people,
departments and systems?
A proven methodology (such as Infosys
InFlux) must be employed to systematically
analyze possibilities, which can lay the
foundation for refined and improved business
processes.
User Experience View
Today, most CIS systems suffer from the ill effects
of a poorly designed User Interface (UI). It is not
uncommon to subject the user to navigate
through a large number of screens to complete
one business transaction; or to screens that are
complicated to use and thus harder to train the
41
users on. Adopting structured methods based on
optimization of workflows and established user
experience designs help improve design. It is
important as the benefits of a good UI are many.
For one, it can reduce the average call handling
time. Secondly, intuitive UI helps reduce training
costs while the number of first-call resolves can
be increased by providing extensive caller
information. The result is increased customer
satisfaction.
There are several proven strategies to
achieve the benefits of optimized workflow.
Following are some of them for call centers:
Structure the screen better: Place the information
regarding the customer that should be visible to the
user at all times on a banner on the top and most of
the commonly used detailed information about the
customer on tabs below the banner. This results in
easy access to customer data and makes the system
more intuitive to use.
Business Workflow Model or Cross-Functional Process Map
Core Billing Process (from periodic billing trigger or ad-hoc request)
Obtain Meter Read and /
or Usage Info
Maintain Meter Reading
Route and Schedule
Validate
Read
Calculate
Usage
Validate
Amount
Apply Billing and
Presentation
Options
Validate
Usage
Compute
Amount
AEH* AEH* AEH* AEH* AEH* AEH*
MEH** MEH** MEH** MEH** MEH** MEH**
Field Service
pickupread,
verifyreadetc.
Field Service
pick up read,
verify read, meter
info etc.
Field Service
pick up read,
verify read, meter
test etc.
Field Service
pick up read,
verify read, meter
info, rate info etc.
Field Service
pick up read,
verify read, meter
info, test, rate info
etc.
R
o
u
t
e
P
l
a
n
n
e
r
M
e
t
e
r
R
e
a
d
e
r
B
i
l
l
i
n
g
S
y
s
t
e
m
B
o
o
k
K
e
e
p
e
r
F
i
e
l
d
S
e
r
v
i
c
e
R
e
p
D
e
l
i
v
e
r
y
M
e
d
i
a
Bill Presentment and/or Delivery Stop
Route and Schedule
Ready Usage
R
e
a
d
Read
U
s
a
g
e
A
m
o
u
n
t
U
s
a
g
e
A
m
o
u
n
t
[Exceptions?] Resolution [Exceptions?] Resolution [Exceptions?] Resolution [Exceptions?] Resolution [Exceptions?] Resolution [Exceptions?] Resolution
[Unresolved
Exceptions?]
Resolved
Exception
[Unresolved
Exceptions?]
Resolved
Exception
[Unresolved
Exceptions?]
Resolved
Exception
[Unresolved
Exceptions?]
Resolved
Exception
[Unresolved
Exceptions?]
Resolved
Exception
[Unresolved
Exceptions?]
Resolved
Exception
[Service
Request?]
Service
Information
[Service
Request?]
Service
Information
[Service
Request?]
Service
Information
[Service
Request?]
Service
Information
[Service
Request?]
Service
Information
B
i
l
l
o
r
S
t
a
t
e
m
e
n
t
* AEH = Automated Exception Handling, a part of Billing System that handles business process exceptions and attempts to resolve them.
** MEH = Manual Exception Handling, the manual process of correcting exceptions, usually employed in complex un-automated cases.
Source: Infosys Research Figure 1: Core Billing Process Workf low at utilities
42
Design screens for major call types: The 80-
20 rule suggests that 80 percent of the calls are
for 20 percent of the call types. The screens can
be designed such that for these 20 percent of
the call types, the user has to navigate to as
few screens as possible, thus reducing the
number of clicks.
Provide more information about the caller and
the call: Automatically store information about
the reason for the call. Every time the user sees
the details of a customer, the system shows a list
of reasons along with times the customer had
called. This leads to the user making a much
better informed decision while responding to the
customers queries.
Technical Architecture View: Service Oriented
Architecture
Service Oriented Architecture (SOA) is
a design style for creating shared, reusable,
distributed services. The principal benefits of
SOA include:
Reuse of common business services across
applications leading to increased
consistency of user experience and data
Standardized and easier deployment,
maintenance and enhancement of services
Flexible IT infrastructure environment to
cater to changing business needs.
The overall flexibility of CIS can be
improved by implementing an SOA which
43
leverages the existing legacy/ home grown
system (Figure 2).
The SOA comprises of an enterprise
service bus which acts as the backbone for
integration and messaging services to help
multiple applications in heterogeneous platforms
communicate with each other. The infrastructure
services provide the common technical services
on top of which the application and business
services reside.
The business services are modeled based on
business processes and thus enable a business-centric
approach to IT implementations. From a CIS
perspective, an SOA offers the following benefits:
Reuse of common business services
across applications leading to increased
costs
The Current investments in legacy back-end
systems continue to stay and be utilized
Multiple applications utilize the same
business service interfaces thus providing
consistent data
Even the batch process applications can
make use of the same business services
thus helping in maintaining consistent
data
Enhancement and maintenance cost of
CIS applications is reduced.
CIS ASSESSMENT FRAMEWORK
The assessment framework guides development
of the knowledge required to determine the need
for transformation, its scope and the outcome of
a go or no-go decision. The objectives of
assessing a CIS are to match resources, improve
efficiency, and demonstrate the value of a future
system. Matched resources align customer
service demands with the resources needed to
serve those demands. Efficiency is improved by
increasing the amount of customer service for
each resource investment and the value of these
changes are illustrated with a business case.
Infosys adopts a three-stage approach
to achieve the transformation of a CIS: assess,
align and alter. The assess stage identifies
opportunities with the current CIS; the align stage
designs the transformed CI S and the alter
executes transformation.
Structure of the Assessment Study
The assessment of a CIS is a four-step task:
1. Establish key performance metrics for CIS
processes
2. Profile the As-I s (current) cost and
performance
3 Optimize the To-Be Service Channel and
Technology Mix for optimized cost and
performance
4. Develop a Business Case to quantify
tangible results. For key perfo rmance
metrics, the ideal measures are
observable, they correlate to the financial
performance of the organization and can
be measured at low cost. These measures
are of two categories: Cost of Service
provided and Level of Service Provided
(which represents customer value).
Examples of simple measures for Cost
of Service Provided include call volume, average
call handling time, billing cost per customer, and
new employee training time. Examples for
Level of Service Provided measures include first
contact resolution rate, percentage of calls
answered within 20 seconds and percentage of
billing error.
The relative importance of each metric
is assessed through the aggregation of a single
cost per customer metric and value per customer
metric from the individual cost and value
components. Examples of these include cost per
call and billing cost per customer.
44
The As-I s performance can be
effectively measured while keeping the costs low
through a randomly selected representative
sample of customer contacts.
The To-Be service channel and technology
mix can be optimized by comparing the baseline
measures with the industry benchmarks and by
analyzing the call and billing processes. Large
differences between baseline measures and
benchmarks highlight areas that need investigation
for business process improvements. For each
viable To-Be scenario the total cost and total benefit
must be assessed.
The optimal To-Be system is selected with
a cost/ benefit comparison of each alternative
system scenario. Each system scenario must
include all business implications and associated
costs and benefits. General alternatives can include
groups of system rewrites, system replacements,
and do nothing.
The final step of the assessment is to
quantify tangible results for the selected
alternative through a business case.
The outcome of a CIS assessment is a
business case that shows total long-term benefits,
investment requirements, net present
enhancement value, and investment risks for the
selected alternative.
CONCLUSION
The experience assimilated from the failures and
successes of CI S and other similar projects
provides a deep insight into what makes for a
success or a failure. Therefore a thorough
assessment of the current situation specific to
ones portfolio of customer service processes
and systems before embarking upon any CIS
initiative is very important. What is imperative
is to establish and document a clear Customer
Service Strategy and then apply it to drive the
CIS strategy. This strategic level direction from
business and IT should then be applied to assess
the As-Is processes, systems and architectural
capabilities. A list of alternative future paths can
then be eval uated to di scover the best
alternative.
It is important to divide the problem
into smaller parts and to prioritize them without
losing sight of the bigger picture. In many cases
a smaller, more specific, and focused CS/ CIS
initiative is a better course of action than a large
CIS replacement.
Finding the best path and drawing a clear
roadmap, however, is only the first step of a long
journey. The challenges are numerous and require
significant project and program management
capabilities from the CIS project team.
REFERENCES
1. Analyst report: Energy CIS / CRM report,
Warren B. Causey, 2001
2. I nFlux
TM
An I nfosys proprietary
methodology and tool for IT solution
blueprinting, accessed July 2005
3. Busi ness pr ocess excepti on
management: busi ness benefi ts of
technology led BPR with billing as an
illustration, Vivek, World of Water
conference, 2001
4. InFin-IT An Infosys Financial Model for
Measuring the Business Value of I T,
Infosys Technologies Limited, accessed
July 2005
5. Ser vi ce- Or i entedA r chi tectur e:
Considerations for Agile Systems,
Lawrence Wilkes and Richard Veryard,
at http:/ / msdn.mi cr osof t.com/
architecture/ soa/ default.aspx?pull=/
l i br ar y / en- u s/ d nmaj / ht ml /
aj2service.asp, accessed July 2005
45
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
How Strategic is building an
Agile Enterprise?
By Vani Vangala
The strategic imperative for agility stems from the
need for improved performance and longer life
expectancy.
S
imply said, an agile enterprise is one that
has the ability to respond to changing
business imperatives and disruptive market
condi ti ons wi th speed and ni mbl eness.
Building an agile enterprise however is by no
means simple.
Enterprises must tread a multi-fold path to agility:
Align Business to Information Technology (IT)
Build flexibility to improve performance
Manage risks of all kinds prudently while
propagating the will to change through
charismatic change agents
Store and retrieve high volumes of data
to facilitate analysis and reporting
Meet Quality of Service requirements.
ALIGNING BUSINESS STRATEGY TO
INFORMATION TECHNOLOGY
The primary building block of an agile enterprise
is alignment of business strategy and IT.
The mode of alignment is based on the
information requirement. In a truly diverse
conglomerate,
The information requirement within each
business will differ
The aggregation and growth parameters
will differ.
Aligning IT with strategy and MIS requirements
from individual businesses is critical and
complex. To chart out the process of aligning
business strategy and I T, the first task for
enterprises is to define the business strategy itself
in terms of long, medium, and short-term
objectives.
Secondly, enterprises must quantify profitability
and resource improvements as part of their
business strategy.
Thirdly, a technology strategy must be defined
that facilitates profitability, resource
improvements, and / or cost savings. The
technology formulation must be followed by
46
identifying Critical Success Factors (CSF) for the
enterprise such as improving customer
experience, broadening footprint, resource
optimization, and so on. The technology strategy
must be flexible, to allow changes
in technological capabilities. Having
achieved the above milestones, enterprises
must develop new resource utilization
models, in tune with its technology strategy.
BUILDING FLEXIBILITY TO IMPROVE
PERFORMANCE
Management specialists recommend various
Dos for organi zati ons that are keen on
building flexibility. Following are a few of
them:
Enhance capabilities that lend competitive
advantages
Release critical resources by outsourcing
activities that are not differentiators in the
competitive landscape
Ensure a high percentage of variable costs
as opposed to fixed cost capital and asset
base
Increase productivity of billable resources
in the services industry
Right size the capacity of a manufacturing
organization
Retain flexibility in decision-making and
other control mechanisms.
RISK MANAGEMENT AND IT
The most common concern of any CXO is to
proactively manage known risks, and to ensure
alternatives whenever encountered by the
unknown. The unknown risks can be categorized
into internal and external. While internal risks
can be controlled by the organizations, external
risks are typically out of the realm of their
control.
Internal Risks:
Internal risks can be controlled by using the
right decision and control mechanisms. Credit
and operational risks are examples of internal
risks.
Credi t ri sk resul ts from l osses
incurred when a borrower or a counter party
fai l s to honor i ts obl i gati ons. I t can be
controlled by ensuring stringent sanction
norms and due diligence before executing a
deal or sanctioning a loan or line of credit. The
control measures require a combination of
systemic and process changes.
Operati onal ri sks are a resul t of
losses due to inadequate internal processes
and can be control l ed by i ncorporati ng
sui tabl e process changes to ensure
compl i ance wi th enhanced i nternal
processes. This too requires a combination
of process and system changes.
The most common concern that CIOs face is managing
risks proactively and ensuring alternatives are available
when faced with unknown
47
External Risks:
External risks are beyond the control of
enterprises and mandate alternative shielding
measures. Market, and demand and supply risks
are types of external risks.
Market risk is a result of exposure to
market dynamics and can only be monitored to
ensure minimal impact of fluctuations in the price
band of the organization.
Demand and supply risk results from losses due
to changes in the demand and supply for
products of the organization. Again this is not
controlled by individual firms and can only be
monitored to ensure minimal impact on long-
term performance.
I T can be effectively leveraged to
minimize the impact of both the internal and
external risks. In the instance of an internal risk,
IT provides the requisite control mechanisms and
process controls to ensure compliance.
I n the case of an external risk, I T
provides organizations with information on
current market dynamics and facilitates tracking
of change between expectation and situation.
ENGINEERING CHANGE
The agile (or adaptive) enterprises develop and
exploit capabilities to thrive and prosper
in a changing, nonlinear, uncertain, and
unpredictable business environment....
(Source: Agile Enterprise Strategy by Paul T. Kidd,
http:/ / www.CheshireHenbury.com)
To engineer change means to ensure a
focused change effort with achievable milestones
and visible commitment from senior
management, to derive sustainable benefits for
the firm.
Agility is possible only if the corporate can accept,
even welcome, change with open arms. To seed
the desire for change in an organization is,
however, a tough task.
CAVEAT
Management literature is subject to fads and the
vagaries of our whimsical minds. While building
agility is the flavor of the day, there are many firms
for whom the cost of building agility into an
enterprise far outweighs the true business benefits.
Or the degree of agility required could be orders of
magnitude different between sectors, industries,
and firms. Clearly then, how agile a corporate
requires to be, is a call each business must take.
CONCLUSION
The requirements of agility are dictated by an
almost biological need for change in businesses
IT helps minimize the impact of internal as well as
external risks -- by providing the requisite control
mechanisms to minimize internal risks while facilitating
access to tackle external ones
48
in our times. There is no avoiding or
circumventing it.
There are mul ti pl e ways of
achieving enterprise agility and in each of
these methods no change can be done unless
the individual chooses to be nimble and to
accept change.
Mutating into an agile corporate is as
fundamental a change as engineering the DNA
of an organism for improved performance and
longer life expectancy.
REFERENCES
1. Individualized Corporation by Sumantra
Ghoshal & Christopher Bartlett
2. Summing Up: Can an Organizations
Deep Smarts Be Preserved?
3. Agile Enterprise Integration (From Agile
Advantage)
4. Agile Enterprise Overview (From www.eds.com)
5. Managing Radical Change by Sumantra
Ghoshal, Gita Piramal & Christopher
Bartlett
49
Strategic Agility Planning for
Banks
Banks need a robust, scalable and
all-encompassing framework for imbibing
agility into their processes.
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
By Prashant Gupta & Prashant Tewari
T
oday, the banking industry needs greater
agility to address challenges such as
vulnerability to economic cycle vagaries,
transient customer loyalties, increasing
regulatory pressures, and heightened
expectations from other stakeholders. Another
agility driver is a need to harness new
opportunities such as Mergers and Acquisitions
(M&A), and new product segments. To address
this imperative, banks must undertake a
structured, well-defined, and strategic planning
to assimilate agility into their Business-As-
Usual (BAU) philosophy.
An agile bank should be able to anticipate change
driver, both internal and external, and respond
faster to beat competition. Agility is a means to
achieve and sustain high performance on all
accounts such as :
Growth / margins
Customer base
Employee satisfaction
IT Infrastructure
Regulatory Compliance
Investor satisfaction
An Agility framework, if adopted effectively,
i s certai n to achi eve the above end state
(Figure 1). The framework can provide banks
with a structured, mutually exclusive, and
exhaustive set of methodologies to initiate,
measure, track, and moni tor agi l i ty
programs.
COMPONENTS OF THE AGILITY
FRAMEWORK
Change Drivers
Change drivers are events or instigators that force
a bank to wish for agility. For example, Mergers
and Acquisitions (M&As) for quick inorganic
growth may be a change driver for a bank that
must diversify its market segments to remain
competitive.
The change drivers can be external or
internal. External change drivers arise out of
50
factors on which banks have little control. They
can range from an interest rate change to more
disruptive changes such as m-commerce, and Net
banking. Internal change drivers, on the other
hand, originate internally: need to rationalize
workforce and improve margins.
In order to identify drivers relevant to the
organization, the first step would be to identify the
dimensions against which changes can be expected
(environment change, M&A, compliance
requirements, staff-related changes, changes related
to IT rationalization and so on). Banks must analyze
each of these dimensions both in terms of quality
and quantity, to detect the emerging change drivers.
Also critical will be a review analysis framework
that will evaluate these change drivers for
validation, and consequent prioritization.
The resultant change drivers will take
the banks one step further on the agility track by
pointing to different strategic directions in which
banks must proceed.
Agility-Enabling Strategies For Change
Drivers: Once a set of validated and prioritized
change drivers are identified, a strategy
framework can be utilized to prepare a detailed
strategy along each element. A detailed roadmap
starting from the current state to the target state
needs must be proposed against each change
driver. This will also define the intermediate
states and both qualitative and quantitative
attributes pertaining to them. Following broad
steps need to be performed to effect this:
Current State Analysis: With specific change
driver as input, a high level As-Is analysis must
be made of the key SBUs of the bank to identify
which of them would be impacted by the change
driver.
Strategy Formulation: As a second step, the bank
should identify the target states, end or
intermediate, for the bank, paths to be traversed
to achieve the target, models/ paradigms to be
challenged in the transition, and risks and
mitigation plans to achieve the path. An overall
program management strategy and tailoring of
organization standards are other areas to be
looked at.
Challenges Review
Attributes
identification for
change drivers
Prioritizing the
change drivers
Mindset changes
Cost spills
Cultural sensitivity
Driver group
identification
Data capture for
metrics
Review panel
identification
Defining scope
boundary for
panel
Define Frequency
Feedback
incorporation
mechanism
Change Drivers
External Change Drivers Internal Change Drivers
Agility enabling strategies against each driver
As is Analysis
Strategy formulation
Goals
Identification
Driver user
groups
Sourcing
Roadmap
Technology
Roadmap
Communication Strategy Costing / Control / Risks
Agility Initiative Tracking Dashboard
Goals /
Timelines
Cost Models
Technology
Roadmap
Controls
Figure 1: Agility Framework
51
Strategy formulation is a result of the
following:
Intermediate/ end goals for each driver/
strategy (could be process/ delivery/
financial goals) for each SBU and linkup
with the different states defined within
the organizational SBU
Identify user group drivers that includes
sponsors, owners, implementers, and
impacted group. Banks must understand
that proper buy-in from these groups is a
critical success factor
Identifying the sourcing areas, options,
locations, models, costs, process
realignment requirements and right
monitoring framework
Realigning the technology landscape are
often necessitated by change drivers. This
will enable banks to put together a long
term technology roadmap with suitable
products, tools, architecture, and
solutions as a part of the roadmap. A
complete technology roadmap will also
cover the adaptations in terms of
methodologies over a period of time. All
this will need a mature transition model
which is aligned with long term IT plan
the organization to be put in place so that
technological agility can be achieved
Another important factor is costing and
its control. It should involve identifying
the qualitative and quantitative costing
parameters, preparation of the costing
models, and their mapping against
already identified roadmap/ states/ goals.
Additionally, an exhaustive set of
measurable parameters and their
monitoring attributes, and their alignment
with strategy as a whole, is a major activity
which banks will need to perform towards
better control on agility initiatives
A detailed risk analysis by risk experts
from different streams like PMO, and
Finance is critical in this journey
Communication strategy will be focused
towards informing stakeholders and
affected groups about the focus areas,
impact areas, path traversed and change
management. Frequency and delivery
will be driven by individual banks agility
strategy preferences
There i s l i kel y to be an overl ap i n
strategi es across di fferent change
dri vers. Consi deri ng that di fferent
change drivers may act at different
poi nts i n ti me, there i s a need for
constant realignment and consolidation
in strategies over time in order to avoid
conflicts and redundancy.
AGILITY DASHBOARD
Cl ose moni tori ng of the program by key
program stakehol ders agai nst key
di mensi ons determi ne the success of an
agility initiative. A dashboard to focus on the
following will keep the different stakeholde
rs informed:
Tracking strategies identified against each
milestone goals / timelines
Getting progress reviewed periodically
against milestones by appropriate forums
Defining key contextual metrics / controls
to measure the progress against
Raising proactive alerts to appropriate
user group drivers, where needed
Dynamic nature of organizations may
necessitate re-aligning the program at
each milestone, if needed, on change
drivers, strategies, goals and so on.
The bank should also review its strategy against
the controls, and rationalize them as and when
required.
52
CHALLENGES AND MITIGATION
One of the challenges that the banks en route
agility may face initially is to proactively track
change drivers. More so if the banks do not have
readily available systems, processes and data to
identify change drivers. This is where an
established Agility Framework can help.
A second challenge is likely to be
identifying the right driver user groups that are
open to changes, are mature and focused, and
have adequate circle of influence in their
respective areas of operations. Though a team
built from the banks internal resources is
definitely helpful, lateral inductions can also be
considered.
Agility initiatives involve changes, most
importantly, of minds. There is a need for
paradigm shift in the mind set of the bank in
order to ensconce agility as a part of Business
As Usual.
Another challenge that must be tackled
is to control the spill-over of program indicators
such as time and cost. Close monitoring, efficient
controls, and excellent program management
skills and methodologies may help banks
overcome this hurdle.
Absence of adequate data may make it
difficult to analyze the (ROI for IT consolidation
necessitated by Agility initiatives.
Implementation glitches such as cost / time
overruns in cosolidation phase are common.
In addition to these challenges, sourcing
vendor realignment and rationalization is likely to
throw up a new set of challenges: defining a
criterion for realignment, evaluating vendors
against that, defining a timeframe for realignment
and instilling processes for avoiding cost / time
overruns.
Capturing Dashboard Data may pose a
challenge because there might be many
qualitative drivers for the dashboard.
A comprehensive framework will help
banks overcome such challenges. Banks typically
operate in more than one location and are likely
to face cultural issues owing to different
organizational ethos prevailing in different
geographies. They must sensitize the overall
governance model to this challenge.
REVIEW STRATEGY
An ongoing review by key participants in the
program, and proactive alerting mechanism is
essential for the success of an agility initiative.
This can be achieved by:
Identifying a panel for review against
dashboard items. The review panel must
have CIOs and CEOs as its members.
Additionally, the review panels should
be di sti nct from the dri ver groups,
although, one driver group could form
a part of the review panel for another
driver group.
Identifying scope for each review panel.
The review panel should review the
overall strategy against each change
driver. It should review the alignment of
the tasks against goals. The review panel
should also continuously monitor the
costing and timelines against those
projected earlier.
Identifying review frequency against each
strategy.
Defining a proactive alerting framework.
CASE STUDIES
Three case studi es are detai l ed bel ow to
illustrate initiatives taken by three banks to
scal e the next l evel of agi l i ty. The case
studi es cover three key geographi es (US,
Europe and I ndi a) thereby i l l ustrati ng
di fferent focus areas i n devel oped vs
developing countries.
53
UK-Based Large High-Street Bank Imbues
Agility in Compliance Programs
Context: The bank had different programs under
way for different regulatory compliance
initiatives (Basel, SOX, and AML). Initially, all
the programs were working in silos and were not
exploiting any cost efficiencies arising out of
leveraging synergies across them. As a
consequence, even a common compliance
requirement was implemented separately by
each program, thereby reducing the banks
ability to manage changes arising thereof and at
the same time increasing costs.
Change Driver: Possible reduction of cost by
leveraging synergies across the compliance
programs.
Strategies: The bank noticed the gap early and
created a PMO-driven organization that took a
holistic view of all the programs and identified,
and consequently leveraged, synergies among
them. A focus group was created that identified
high level common areas based on a two-month
study (areas such as Business and I T
requirements gathering, I T infrastructure
components, testing strategies, and deployment
strategies). The organization also defined the
realignment modes.
Tracking: A focused group was identified to
monitor the progress against each common areas
identified. A Review model was established to
take care of realignments required, if any. The
program created metrics around monitoring cost
savings against each common area and closely
monitored against them.
Benefits: This management approach of the
programs enabl ed the bank to reduce i ts
overall cost, consolidate its IT stack, be more
proactive in carrying out future changes in the
evol vi ng compl i ance needs, and gai n the
confidence of regulators. As a corollary, the
bank now has good systems, processes and
people in place to take a holistic view of any
new compl i ance requi rements before
embarki ng on i mpl ementi ng them across
different programs.
US-Based Large Bank Consolidates Vendor
Portfolio
Context: The bank had a large IT organization
that was sourced both internally and through
multiple external vendors. Applications were not
clearly aligned along the banks business / IT
dimensions leading to duplication of I T
infrastructure, effort, and consequent risks, and
cost escalation.
Change Driver: Cost reduction by portfolio
realignment and consolidation.
Strategies: In order to improve margins, reduce
risks and consolidate its IT infrastructure, the
bank is consolidating its vendor base. As a result,
outsourcing portfolios are being rearranged
based vendor capabilities, service offerings, and
technologies. The vendors are being short listed
from the existing portfolio by analyzing the key
strengths demonstrated over the past few years.
Monitoring: The bank created a monitoring
center of excellence, which is responsible for
conceiving interventions and their execution
framework. The center monitors the progress of
initiatives through predefined metrics that are
aligned along business objectives.
Benefits: Vendor consolidation has enabled the
bank to reduce vendor management bandwidth,
improve costs, and reduce risks. In the long run,
the initiative is likely to achieve higher service
and process maturity.
India-Based Private Sector Bank
Context: The bank is the largest private sector
bank with branches across India and wished to
take the services and operational efficiencies to a
higher level through IT-focused interventions.
54
Change Driver: Increased revenue / margins
triggered by enhanced IT effectiveness.
Strategies: The bank adopted a proactive
strategy to undertake a massi ve
computeri zati on dri ve very earl y by
purchasing state-of-the-art products in its lines
of busi ness, connecti ng al l branches
electronically, and proactively identifying, and
provi di ng l atest features to cater to the
changing customer preferences and creating an
information base for existing and prospective
customers.
Monitoring: The bank monitored the progress
of its initiatives against cost, branches, and customer
preference changes. It adopted an organization-
wide policy of time-bound implementation leading
to faster time to market.
Benefits: The increased agility arising out of the
high-level of automation has enabled the bank
to demonstrate above-average growth rates, loyal
customers, increased margins, and ever
improving product portfolio as compared to its
Indian competitors.
As the cases illustrate, agility can be
instilled in any given initiative by identifying the
change drivers early in the project lifecycle, to
derive definite business benefits (Table 1).
CONCLUSION
Banks across the world are striving hard to
become more agile than they were earlier. A
change in mindset is as essential as a structured
approach for instilling agility in the banks
processes and take it to higher levels. The
framework detailed above is likely to help banks
in their pursuit of Agility.
REFERENCES
1. Enterprise AgilityWhat Is It and What
Fuels It? Rick Dove, Issue Alert, 10/ 29/ 04-
2. An Agile Age Gartner Study, sponsored
by BT, July 2002
3. What Are The Components Of An IT
Operations Scorecard Craig Symons
with Laurie M. Orlov, Forrester Research,
June 2005
Sustained High growth
Sustained High Margins
Loyal and increasing customer base
Sustained High employee satisfaction
Scalable, Robust and state-of-art IT Infrastructure
Sustained High Regulatory Compliance
Sustained High investor satisfaction
Agile business process
US Bank Indian Bank EU Bank
Table 1: Summary of benefits achieved by the above banks (internal research)
Benefits
55
Software engineers stand to gain by inducing
agility into the development process.
C
ritics often say that agility is merely
waiting for bad things to happen, and then
responding. It is a fancy name for lack of planning
and ad hoc-ism. But for the rest, agility is a way
of life, a constantly emerging and changing
response to business instability.
To discuss agility as an option for
Software Engineering Processes (SEP), what
follows is a case study. The case study discusses
the processes followed during enhancement of
an application and how they can be replaced by
Agility.
CASE STUDY
Brief Description of Application
The client ABC, a leading telecommunication
service provider, has a J ava-based Web
application. The employees of the company use
the application to make different types of
requests to another company XYZ that provides
basic infrastructure.
In the process, user at ABCs end makes
a request through the application. The request
goes to XYZ, which responds with its comments.
On receiving a reply, ABC puts the data into the
database to store it for future references and for
yet another reporting application used internally
by ABC.
Due to changes in some communication
guidelines specified by XYZ, apart from their
communication process, ABC had to design a
form that can input the response received from
XYZ. When saved, the response gets stored in
the database. The data thus stored is further used
by ABCs reporting tool to generate reports.
Implementing the Software Process Lifecycle
A detailed description of what goes into
application enhancement helps understand the
development life cycle, and causes for loopholes,
better. Following is a step-by-step account of an
application development exercise:
Feasibility Study and Requirement Gathering
This is the first step in developing the software
during which the client gives information about
necessary enhancements. A feasibility study is
conducted, which includes understanding of the
application and calculating the impact of the
SETLabs Briefings
VOL 4 NO 1
July - Sep 2006
Agility in Software
Engineering Processes
By Shaurya Vardhan Garg
56
solution on the application itself or on other
applications.
The client is questioned here to gather
the requirements. To have clear and objective
requirements from the client, it is good to have a
basic design ready. It not only helps in efficient
requirement gathering but also in preparing a
basic design to start the development.
Accordingly the supporting team
documents all the requirements in a standard
format for the use of developers to develop the
desired solution.
Design: During the design phase, the project
team prepares the detailed design of the solution
to be implemented. The design document
typically has a detailed description of all the
changes that will be made during the
development of the solution, i.e. all the files that
will be changed and all the new functionalities
that will be put into the code.
Since it was a maintenance project,
design mostly contributed to the change of files
rather than new development of files. But
because this was a major enhancement, some new
code files were also to be created.
Coding: This phase includes the coding of the
solution by the developers. Usually the developers
are good programmers but sometimes application-
specific training is required for the developers. The
best way is to segregate the whole coding effort into
smaller efforts.
The project team is divided into a set of
programmers or developers. After completing
the days work, the team meets to discuss the
progress and to check compatibility of each
others code.
Coding is generally followed by Unit
Testing to avoid defects.
Integration Testing: Once all the modules are
ready, they are integrated into an application and
then tested. After a round of self testing, testing
is done by peers and reviewers followed by a
System Testing.
Client Demo: The application, after having
undergone rigorous testing, is demonstrated to
the client and changes, if any, are made to the
running application.
Changes Incorporation: Changes specified by the
client in the above step are incorporated. The
testing exercise is repeated after the changes have
been done.
Acceptance, Installation, and Deployment: The
application is deployed to the development
environment at the clients end by the supporting
team. It is further sent for User Acceptance
Testing. Usually at this stage, a user assigned by
the client works on the application and ensures
that the required business functionality is
achieved.
If the general user finds any defect, it is
set right by the development team. Once the
supporting team gets a nod from the clients end,
the application is deployed to the Production
Environment. Now the application is used by
general users at the clients end.
Maintenance: Once the development of the
application is complete, the next step is to
maintain the application which is done by a
supporting team.
THE NEED FOR AGILITY
A typical application development
lifecycle such as above, contains several loopholes
that causes delays. Mentioned below are a few
such loopholes:
1. The first and foremost task is to gather the
requirements of the client. A complete and
exhaustive list of requirements is
necessary if blunders and delays are to be
avoided. The client is asked for the
business requirements. After the business
requirements are fully understood, the
57
changes to be made are taken note of. The
process of collecting and understanding
the requirements consumes a lot of time.
Understanding the requirements is not
enough-they should be clearly
documented. There are usually two teams
involved in the development process: a
supporting team, which interacts directly
with the client, and a development team,
which relies on the information provided
by the former to develop a solution.
2. Preparing a detailed design of the
requirements and processes to be
followed during the development
consumes time. If it is a maintenance
project, the code for the application is
already available but often difficult to
understand. The developers of the
original application may not have
incorporated comments making it
difficult for the current team to
understand the code. Again, once
deciphered, it must be clearly
documented.
3. Coding depends on developers who must
possess sound domain knowledge -
implementing this theoretical knowledge
into working software may however take
more time.
4. Finally, testing takes considerable amount
of time. It is the gateway to the client and
should be done as thoroughly as possible.
HOW CAN AGILITY HELP?
Agility can help speed up the software
development lifecycle. Advocates of agility
believe in following the four focal values:
1. Replace processes and tools with
individuals and interactions
2. Replace comprehensive documentation
with working software
3. Replace contract negotiation with
customer collaboration
4. Respond to a change rather than following
processes.
Replace processes and tools with individuals
and interactions: Software Development Life
Cycle (SDLC) is more a process-oriented activity.
Developers have to follow the processes to
understand the requirements. A better way of
doing it is to have brain storming sessions within
groups to elicit different viewpoints to the same
concept. Rather than opting for only one option
and going that way, it is good to have many
options and selecting the best out of it.
I n the software industry, good
understanding and logical reasoning are some
of the basic requirements that a programmer
must have. During system understanding, a lot
of assumption - not necessarily correct ones - are
made to arrive at a working solution. It is possible
that a programmer considers only one aspect
while ignoring others. I ndividuals, and
interactions between them, are more result
oriented (Figure 1).
Replace comprehensive documentation with
working software: The main objective of a
software team is to deliver a quality product.
New changes must be incorporated at frequent
intervals even on an hourly or daily basis (but
usually on a bi-monthly or a monthly basis).
Developers should keep the code as simple,
straightforward, and technically advanced as
possible. Documentation essentially means
translating a concept into words, therefore
ambiguity proves costly.
Replace contract negotiation with customer
collaboration: The relationship that the project
team shares with the client and the cooperation
between them must take precedence over
contracts. The negotiation process should be seen
as a means of achieving and maintaining a viable
58
relationship. From a business point of view, agile
development is focused on delivering business
value as soon as the project starts (Figure 1).
Respond to a change rather than following
processes: The development group should
comprise both software developers and customer
representatives. This group should be well-
informed, competent, and authorized to consider
possible changes during the development
lifecycle. This means that the participants are
prepared to make changes and also to the existing
contracts (Figure 1).
Hackers, for example, believe more in
agility than in inch-pebble iron-bound contract.
One of the basic requirements to go the
agility way is to have developers with domain
expertise. This not only helps in responding to
the clients requirements quickly but also helps
in producing quality software.
The four focal values speed up the SDLC
while delivering a quality product to the client:
1. Time spent during documentation of
requirements can be saved to a great extent. A
model can be developed every time the client
specifies some requirements.
2. If coding is done while gathering
requirements, time and effort need not be
expended on a detailed design.
3. Again coding time is eliminated
from the SDLC because the code has been
prepared.
4. Agility can save a lot of person-hours.
A module must go through rigorous testing: by
developers, by their peers and their clients. As
the client is involved all along the SDLC, there is
no need for a client demonstration. In short,
agility saves time and effort.
CONCLUSION
Agile methods focus on people, their interaction,
working software, customer collaboration, and
change rather than processes, tools, contracts, and
plans. Though agile methods provide a quick
solution to the software development, they are
rarely practiced.
Agile methodologies are new to the
software industry. There are risks, which hinder
its use. There is, however, little doubt that agility
helps reduce time spent on various activities, and
once in practice, it can prove to be a boon to the
software industry.
REFERENCES
1. Agile Software Development Ecosystems
by J im Highsmith, Addison-Wesley,
March 2002
2. Balancing Agility and Discipline by Barry
Boehm and Richard Turner. Addison-
Wesley, August 2003
3. Agile and Iterative Development by Craig
Larman, Addison-Wesley
4. http:/ / agilemanifesto/ org
5. http:/ / www.agilemodeling.com/
SETLabs Briefings
BUSI NESS I NNOVATI ON through TECHNOLOGY
SETlabs Briefingsis a quarterly published by Infosys Software Engineering
& Technology Labs (SETLabs) with the objective of offering fresh
perspectives on boardroom business technology. The publication aims at
becoming the most sought after source for thought leading, strategic and
experiential insights on business technology management.
SETLabs is an important part of Infosys' commitment to leadership in
innovation using technology. SETLabs anticipates and assesses the evolution
of technology and its impact on businesses and enables Infosys to constantly
synthesize what it learns and catalyze technology enabled business
transformation and thus assume leadership in providing best of breed
solutions to clients across the globe. This is achieved through research
supported by state-of-the-art labs and collaboration with industry leaders.
Infosys (NASDAQ:INFY) defines, designs and delivers IT enabled business
solutions. These provide Global 2000 companies with strategic differentiation
and operational superiority, thereby increasing firm competitiveness, Infosys
combines technology, tools, methodologies, processes, knowledge
management, business insights and deep rooted organizational values to
deliver solutions. With Infosys, clients are assured of a transparent business
partner, business-IT alignment with flexibility, speed of execution and the
power to stretch the IT budget by leveraging the Global Delivery Model
that Infosys pioneered. To find out how Infosys can help businesses achieve
competitive advantage, visit www.infosys.com or send an email to:
improvemyodds@infosys.com.
Editorial Office: SETLabsBriefings, B-19, InfosysTechnologiesLtd.
ElectronicsCity, Hosur Road, Bangalore560100, India
Email: SetlabsBriefings@infosys.com
http://www.infosys.com/technology/setlabsbriefings.asp
Editor
George Eby Mathew
AssociateEditors
Amit Sharma
Srinivas Padmanabhuni
Consulting Editors
Krishnan Narayanan
Prasad J oshi
DeputyEditors
Praveen Bhasa Malla
Sumanta Deb
CopyEditor
Anupama Gummaraju
Graphics/WebEditors
Ramesh Ramachandran
Sanjay Eknath Nayak
Marketing Managers
J acob Varghese
Kanupriya Sindhu
Vijayaraghavan T S
Production Managers
Sudarshan Kumar V S
V H Suresh Kumar
How to Reach Us:
Email:
SETLabsBriefings@infosys.com
Phone:
+91-80-41173896
Fax:
+91-80-28520740
Post:
SETLabs Briefings,
B-19, Infosys Technologies Ltd.
Electronics City, Hosur Road,
Bangalore 560100, India
Subscription:
vijaytsr@infosys.com
Rights and Permission:
george_mathew@infosys.com
Reprints:
jacob_varghese@infosys.com
2006, Infosys Technologies Limited
Infosys acknowledges the proprietary rights of the trademarks and product names of the other companies
mentioned in this issue. The information provided in this document is intended for the sole use of the recipient
and for educational purposes only. Infosys makes no express or implied warranties relating to the information
contained herein or to any derived results obtained by the recipient from the use of the information in this
document. Infosys further does not guarantee the sequence, timeliness, accuracy or completeness of the information
and will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of, any of the
information or in the transmission thereof, or for any damages arising there from. Opinions and forecasts constitute
our judgment at the time of release and are subject to change without notice. This document does not contain
information provided to us in confidence by our clients.
NOTES
Authors featured in this issue
AKASH SAURAV DAS
Akash Saurav Das is a Technical Specialist with the Web Services Center of Excellence at the Software Engineering &
Technology Labs, I nfosys. His current areas of research include, among others, XML compression, web services
security, semantic interoperability, UDDI , and web services for remote portlets. He has publications to his credit, in
refereed proceedings of international conferences. He can be reached at akash_das@infosys.com
ANANTH CHANDRAMOULI
Ananth Chandramouli is a Solutions Manager with I nfosys. He has several years of experience in technology consulting
and developing solutions for critical business problems in various industry verticals, including energy utilities. He
can be reached at cananth@infosys.com
CLIFTON L. MUHAMMAD
Clifton L. Muhammad is a Case Leader with I nfosys Consulting, I nc. He has over seventeen years of management and
consulting experience in the energy and utilities industries. He can be reached at clifton_muhammad@infosys.com
JAI GANESH
J ai Ganesh, PhD, is a Senior Research Associate with the Web Services Center of Excellence at the Software Engineering
& Technology Labs, I nfosys. His research focuses on web services, I T strategy and adaptive enterprises. He has
published in several peer- reviewed journals and international conferences. He serves as a reviewer for a number of
peer-reviewed journals and conferences. He can be reached at jai_ganesh01@infosys.com
NAYAN JYOTI KAR
Nayan J yoti Kar was a Software Engineer with the I nsurance, Healthcare and Life Sciences business unit at I nfosys.
He was associated with projects which involved modernization of legacy applications.
PRASHANT GUPTA
Prashant Gupta is a Senior Consultant with the banking group at the Domain Competency Group,I nfosys. Prashant
has more than a decade of experience in I T services and corporate ratings. He has been a solution architect for
banking organizations in compliance and other related domains. He can be reached at prashant_gupta01@infosys.com
PRASHANT TEWARI
Prashant Tewari is a Project Manager with the Banking and Capital Markets business unit at I nfosys. Prashant has
twelve years of experience managing development, testing, turnkey implementations and production support projects
in the investment banking domain. He can be reached at prashant_tewari@infosys.com
SANDEEP GAIKWAD
Sandeep Gaikwad is a Software Engineer with the Web Services Center of Excellence at the Software Engineering &
Technology Labs, I nfosys. He has worked on axis web services. His recent work centered on the Sun ONE application
server and examined among other issues, its interoperability with other servers, security for web services and ws-
security implementation. He can be reached at sandeep_gaikwad@infosys.com
SHAURYA VARDHAN GARG
Shaurya Vardhan Garg is a Software Engineer with the Communication Service Providers (CSP) business unit at
I nfosys. He can be reached at shaurya_garg@infosys.com
SRIRAM ANAND
Sriram Anand, PhD, has over twelve years of industry and research experience. Sriram is a Principal Researcher with
the Web Services Center of Excellence at the Software Engineering & Technology Labs, I nfosys. His current research
interests include enterprise architecture, service oriented architecture, legacy integration and software engineering
methodologies. He can be reached at sriram_anand@infosys.com
VANI VANGALA
Vani Vangala is a Solution Consultant with the Finacle business unit at I nfosys. She has several years of experience in
implementing financial services products. Her area of work in financial institutions involves people and process
changes, which serve as inspiration for change management articles. She can be reached at vani_vangala@infosys.com
VIVEK
Vivek is a Senior Principal with the Energy, Utilities and Resources business unit at I nfosys. He has about ten years of
experience in shaping customer information systems at public utili ty companies. He can be reached at
vivek@infosys.com
VIVEK RAUT
Vivek Raut is a Software Engineer with the Asia Pacific (APAC) business unit at I nfosys. He has co-developed a
methodology for migration of legacy applications using SOA. He has publications in a leading web services journal to
his credit. He can be reached at vivek_raut@infosys.com
Subu Goparaju
VicePresident
and Head of SETLabs
At SETLabs, we constantly look for opportunities to leverage
technology while creating and implementing innovative business
solutions for our clients. As part of this quest, wedevelop engineering
methodologies that help Infosys implement thesesolutions right first
timeand every time.
For information on obtaining additional copies, reprinting or translating articles, and all other correspondence,
pleasecontact:
Telephone : 91-80-41173878
Email: SetlabsBriefings@infosys.com
SETLabs 2006, Infosys Technologies Limited.
Infosys acknowledges the proprietary rights of the trademarks and product names of the other
companies mentioned in this issue of SETLabs Briefings. The information provided in this document
is intended for the sole use of the recipient and for educational purposes only. Infosys makes no
express or implied warranties relating to the information contained in this document or to any
derived results obtained by the recipient from the use of the information in the document. Infosys
further does not guarantee the sequence, timeliness, accuracy or completeness of the information
and will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions
of, any of the information or in the transmission thereof, or for any damages arising there from.
Opinions and forecasts constitute our judgment at the time of release and are subject to change
without notice. This document does not contain information provided to us in confidence by our
clients.

SETLabs Briefings Enterprise Agility

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SETLabs Briefings Enterprise Agility

Uploaded by

Copyright:

Available Formats

SETLabs Briefings

You might also like