Infosys-Oracle Blog

Often I come across the discussion on whether a company or a unit should go for Value based segmentation or a Need based segmentation. Customer A,B,C are most worthwhile to me and XYZ are low value customers and therefore let me find ways to service low value customers at a lower cost, through self service channels, reduced customization, etc. or target most profitable customers within each segment for initiatives to increase retention & wallet-share

Segmentation is an integral component of any company’s strategy to gain an edge over their competitors or must say achieve a sustainable competitive advantage. Any company would like to be profitable by increasing revenues (via increasing penetration of attractive segments, growing the more customer attractive segments, retaining the existing customers) or reducing the operational expenses (more effective and efficient (read low costJ) marketing campaigns, reduced sales & service costs etc)

Many companies view segmentation as dividing customers into high, medium and low value brackets, measuring the customer’s gross or net contribution margin. The reason behind such value based segmentation is; one the required information tends to be readily available and second the goal of attracting and retaining the highest value customers would logically have a high ROI

However the major issue with the above stated “value-based” segmentation is that it assumes that all high-value customers have identical needs and preferences which is not the case most of the time. Therefore, a “needs-based” segmentation will have far more impact on determining what combination of products and services will be required to create a compelling value proposition for different customer segments.

Needs-based customer segmentation involves dividing your existing, and potential, customers into distinct groups that have similar needs, preferences and satisfiers.

• Needs: What all needs of a particular segment can be fulfilled by your company? i.e. what all products and services are best suited to meet those needs? 
• Preferences: How does a segment prefer to interact and transact with a company?
• Satisfiers: Among varied options available, which solution set would a segment choose to fulfill a given need?

Posted by Amandeep Singh Syali at 09:39 AM | Permalink | Comments (5) | TrackBacks (0)

The last month and a half has been exciting! The ardent cricket fan in me has been treated to some rapid fire cricket through the Indian Premier League 20:20 extravaganza. Round about the same time, my project team also started rapid application development using SCRUM, a methodology I would call the 20:20 version of the waterfall model of software development. Interestingly, the word SCRUM also has its origins from the sport of rugby where a “scrum” is a group of people responsible for picking up the ball and moving it forward.

For the uninitiated, SCRUM is a relatively new software development methodology that uses an iterative and incremental process for developing software. It is one of the various agile software development methods like Crystal, Extreme Programming (XP), Open Source Software Development (OSSD), Agile Methodology (AM) etc.

A SCRUM consists of a series of less than thirty day sprints, with each sprint producing an executable. It is a “lightweight” development process since it focuses on completion of limited features based on select high level functional requirements. The objective is to iteratively build software through sprints with each sprint generating a standalone demonstrable entity. There is no big bang requirement gathering and design phase but a piece by piece progression in development. As more and more sprints are completed, both the product and the project team evolve. A SCRUM can also have Spike teams that are responsible for setting the business and technology level direction across sprints.

Scrum methodology is known to address one of the biggest pain points of the Waterfall Model, namely the linear nature of work. In a lot of projects, the requirements change during the development lifecycle and the business users find that the end product is totally out of sync with their requirements. An iterative, flexible and collaborative approach like SCRUM is said to be very suitable for dynamic design scenarios or in cases where clients have IKIWISI (I’ll Know It When I See It) type of requirements.
To be very frank, when I first heard about the SCRUM methodology I was a little skeptical about its effectiveness and delivery quality. A quick search on the Internet revealed that there are several projects where managers are happy with the outcome of this methodology. Large corporations like Microsoft have also employed it successfully to ensure faster product turnaround times. I had a conversation with some of my “very tired” project team members who were fresh out of the experience of executing a Sprint. They seemed pretty satisfied with the outcome of the methodology but brought out some salient points saying—“The success of the methodology depends on having skilled resources at your disposal and having very good Sprint Planning. Small emergencies like a team member falling sick can set the plan back quite a bit.” Given the length and size of our development effort, we need to see how each sprint progresses. My project team and I are eagerly waiting for the final outcome, to see if we can move more modules to this methodology!

It would be good to know if any of you have any prior experience with Rapid Application Development Methodologies and can share any learning’s/thoughts on it. Your comments are highly appreciated!

Posted by Padmini Ramakrishna Talagavaram at 11:29 AM | Permalink | Comments (6) | TrackBacks (0)

Let me explain two important concepts- One of the most important concepts is the way retailers report their financials, they use a 4-4-5 calendar with February often being the starting month. This gives them a very good way of comparing sales on period on period basis, since each period every year has the same number of selling days. It also acts as the best way to divide the entire year into periods with an equal number of weekends, which is when the retail sales are the highest.

The other main difference in retail accounting is the way company profits are calculated.

Sales Cost – Cost of Merchandise sold = Gross Profit

Gross Profit – Operating expenses = Net Profit.

 The two main kinds of costs associated with retailers have implications for how the business divisions are organized, systems are implemented and financial reporting is done. The most common terms for these two main costs are Merchandise Costs (or costs incurred towards procuring Goods for Resale) and Expense (costs incurred in procuring Goods not for Resale). The nature of these two entities of the retail business are very different, merchandise transactions are usually high in volume and spread across a larger base of steady suppliers. The Expense transactions are lower in volume and are spread across a base of transient suppliers (including several one-time only suppliers), employees (payroll costs) or other vendors of services and goods.

These two concepts have clearly established a case for a new perspective on Implementing Retail Financials as opposed to implementing merely financials for Retailers

Posted by Venu Kotamraju at 10:46 AM | Permalink | Comments (2) | TrackBacks (0)

Corporations today are spending significant amount of time and money in deploying state of the art ERP software like Oracle, SAP etc. IT management in these big corporations is more concerned to get the software deployed and then they consider their job is done. To say the truth the job is not even half done in most cases. The fail to recognize an important parameter - the ability of the system to perform as per "expectations" after the system has been deployed.