Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« March 2013 | Main | May 2013 »

April 18, 2013

Standardization vs. Personalization - Where do you draw the line of equilibrium?

In my previous blog, we identified the drivers causing a continuous tug of war, for an enterprise, between standardizing the business operations and IT assets AND meet the consumer's demand for an increasingly personalized product experience. However, with the realities today being limited resources, fast evolving technology and convergence of a multi-vendor marketplace, organizations, in order to survive and accelerate, need to redraw the boundaries to answer questions like
  • What should be standardized?
  • How much should be customized?
  • Where should we begin?

While cost of investment and time-to-market are essential drivers towards answering these questions, the problem statement is defined by the OUTCOME - an outcome that allows businesses to simplify operations and remain flexible and agile enough to meet customer demands.

A new consumerism is emerging - one that demands shared experiences. In hunting for the new order of things therefore, it is necessary to start and evolve with the new digitally equipped customer. The essential questions which organizations are asking themselves have changed from ones based on cost to those based on customer engagement and customer equity.

  • How would the standardization of a system / function affect my customer's experience with products / services?
  • How would standardization of a system / function affect the way in which my customers interact with me?
  • How would standardization of a system / function affect the way my customers talk about me?

Let's understand this better with the help of an example of a business selling personal computers with a high degree of configurability to retail customers via online and telephonic channels; with a promise of fast and free delivery and best in class after sales support.

  • For some functions like payroll, corporate finance etc., standardization solution may be a platform which incorporates industry's best practices.
  • For functions like portal payment systems, customer relationship management etc. a standardized solution is an absolute NO GO as these have a direct impact on the customer's experience.
  • Functions like supply chain logistics, maintenance outsourcing etc. have partial impacts on the business value proposition and standardization must ensure that the processes and handoffs built-in warrant minimal / no negative impact to the customer's experience. 

All in all, the closer a system / function is to the end users in a value chain; the lesser will be the degree of standardization. However, it is a tightrope walk to draw out the line of equilibrium mapping the correct path. But, as the line gets drawn out, it will decide between the businesses those will succeed and those which will fade into oblivion.

With low investments, fast returns and low risks being the minimum expectations for any large scale transformation, the line of equilibrium, in actuality, is the critical path to success.

April 8, 2013

A Lesson from Bollywood for Outsourcing

Posted by Suman Sasmal - Vice President and Service Delivery Head, CORPBITS, Infosys


Bollywood superstar, Amitabh Bachchan has managed to stay relevant over the years by constantly re-inventing himself. Is there a lesson here that one of India's greatest exports can give to another?
IT outsourcing business has become rapidly commoditized yet the dynamics have changed so much that cost and efficiency alone are no longer the sole motivators for outsourcing.

The industry is slowly but surely reinventing itself to go from being an efficient supplier of services to a strategic partner enabling business outcomes. The innovative ways vendors take to re-define themselves in a rapidly changing economic environment can put them right on track to achieve Outsourcing Superstardom.

To know more, click here

 

April 4, 2013

Standardization - Can it support today's "personalization" needs?

Standardization.jpg
Remember the time when a mobile was just an instrument used to make a phone call on the move and came in limited price bundles? That was the level of customization offered by wireless service providers and OEMs. Today, the end customer demands a complete smart phone experience with abilities like plugging in his cable provider to schedule DVR recordings, reading his email, view real-time traffic, and weather news etc. All this, while continuing to provide him with the ability to talk and send messages. So, an AT&T partners with a Samsung which in turn partners with Google to provide the necessary platform and connectivity to the smart phone. Other providers like Comcast, CNN and others leverage this platform to provide geo-synced news and weather. Very soon, service features like home security controls and smart home controls will become popular on the smart phone too. This will add at least a dozen more vendors and multiple services to this already complex ecosystem. Such a multi-vendor eco system requires a level of standardization to the platforms and interfaces across these vendors. At the same time there is a need to accommodate the customer's demands and preferences of service...

Two trends are ruling the market today. One, a customer who is at the center of the value creation process and is demanding to co-create a unique experience and two, the marketplace, which is rapidly transforming into an eco-system with multiple enterprises converging and providing the customers with the final experience. In the past, the enterprises were required to provide only a limited degree of flexibility to cater to customization at a market segment level. In an ideal world with a lesser limitation on resources, this would have led to customization of ALL IT assets to cater individual consumers with complete personalization. However, with the growing cost pressures on IT and business, there is a significant bias towards standardization as an underlying philosophy towards IT investments.

Standardization, with itself, brings a quiver full of benefits which helps cater to a growing customer base. It not only helps improve the speed to market but also helps the business operations react better to customer demands and be modular across the value chain. All of this at lower operational and maintenance costs! The adoption and proliferation of shared and managed service models across IT and business operations are great examples of how 'standardization', as a practice, has proved beneficial.

While shared and managed service models have reached their maturity, there is still a burning need to provide complete personalization. This has resulted in a continuous tug of war across the application landscape where the enterprise wants to standardize the business operations and IT assets AND yet meet the consumer's demand for an increasingly personalized product experience.

 Its remarkable how configurability has been incorporated into the concept of "standardization" to deliver successfully in such a demanding environment. The questions that pose themselves are ones of equilibrium between the past that has seen standardized IT assets and the future of customer driven personalization of services. Where do IT organizations draw the line between standardization and personalization? Will standardized apps offer the experience that customers are demanding?

In a situation where "Personalization" is the buzz word, will standardized applications meet the expectations of the consumers? And increasingly the answer to this question is defining the roadmap to profitable growth into the future.

April 3, 2013

Feature Engineering vs Sustain Engineering - The debate continues

Feature Engineering [FE] and Sustain Engineering [SE] form the two most important work streams in any large engineering service delivery program.

Feature Engineering [FE] involves design, development, testing and deployment of "new features" in a product. This work stream requires requirements engineering and therefore demands a closer interaction with the business groups and product users.  

On the other hand Sustain Engineering [SE] deals with the task of keeping the "house in order". Ensuring that the existing production systems behave as intended and resolving critical production issues forms the crux of SE. Sustain Engineering requires a thorough understanding of the system and close interaction with the Production Support teams and also Product Users.

So which is important?  - Feature Engineering [FE] or Sustain Engineering [SE]. Without a doubt we all know that the answer is BOTH - but it's not that simple.

I have been a part of both of these work streams as a developer and more recently managing both these disciplines for large programs. As a person responsible for both Feature and Sustain engineering it becomes difficult to manage priorities and affiliations. We have had intense discussions and debates within Infosys about these two disciplines. However, ultimately it's what the customer wants that matters most.

For a Developer or Tester in the program there is always a question about which stream is more important and interesting?  More regarded and respected? And above all which stream is considered "important" by their managers for the recognition of their work and important for "visibility" within the organization.

Managers always have a challenge about the right skill-fitment and resource allocation to these work streams.

• Should a junior engineer who lacks experience be a part of Feature or Sustain?
• Which stream requires more Domain Knowledge and Expertise?
• Which work stream helps in skill development?
• How to keep the all the teams motivated -be it Feature or Sustain?

In a large Agile program there could be multiple Scrum teams that are working on Feature and Sustain and that makes the above questions more challenging.

I have tried to de-construct the "DNA" of a Feature and a Sustain engineer below.

I am a Feature Engineer and therefore,

I am a Sustain Engineer and therefore,

 

I am responsible for new features in the product that are planned by the business groups for product enhancements.

 

 

I am responsible to ensure that the current production system behaves as per design and there are no bugs in the existing system

 

I depend on Business Requirement Documents (BRD) to know what I need to develop or test

 

 

I refer to the Functional Specification (FS) and anything that is expected which is not documented in the FS is classified as a "Change Request"

 

 

I need not know much about the whole application as I am responsible for only a  particular feature

 

I should have a good idea of the breadth of the application for me to succeed as Bugs can be anywhere in the application.

 

 

Even though I am fresh out of school I can be a part of feature engineering.

 

 

I need to have prior experience to be a part of sustain engineering

 

 

My work is more important than Sustain because I am working on "New Features", not mere maintenance of the existing system

 

 

My work is more important than Feature because I am keeping the Lights-On. If something goes wrong in the production system all hell breaks loose.

 

 The debate, however, is a never ending one...