Consolidation in ISV business, It’s truly happening!

There is so much talk in the market about the consolidation of enterprise software companies.  While high profile deals are happening, in large numbers, I was still not sure if there is truth in the story on an industry-wide basis.

My recent quick calculations looking at software industry profile published by SIIA, comparing it against their data published in 2004 gave a quick clarification that consolidation is, truly happening.

Yes.  Consolidation is happening at all levels – be it by M&A or by natural evolution – survival of the fittest.

Look at the statistics:

SIIA reported 23,311 companies in the USA in their report titled Software Industry Profile June, 2004.  In their recent report Zapdata Industry Profile, January 2006, the number of companies have come down to 18,939.

More interesting is the fact that ISV companies above 100 employees in size – 462 of them in 2004, reduced to 409 of them in 2006.  The 462 companies above 100 employees in size generated 85.5 Bn in revenues in 2004, and now, the reduced number of companies, 409 of them produce 96.5 Bn in revenues.

To refactor or not, the classic dilemma for ISVs

Current dollars Vs future dollars:  To re-factor or to run with the current code-base?

It is a classic dilemma for ISVs.

If you are running a software product company, you probably are very familiar with these conversations…

- The current code-base is not designed product-class. 
– It takes too much time to make any changes. 
– It is built using archaic technologies – we need to change it to the current technologies
– We need to reengineer so that all the customizations can actually be configurations
– If we reengineer the core product, we can cut customer implementation time by half
– We are not able to do any regression testing as the code-base is not coherent
– We cannot automate testing due to the way the code base is built
– Reengineering?  You must be kidding!  That is too much effort.  Not worth it!
– Our developers are too busy attending to the maintenance and enhancement issues thrown by customers.  How can we leave the revenues that can be earned by fixing immediate customer issues and focus on reengineering for the future?
– I agreee. Ideally, we should take a team out to look at reengineering efforts independently – but where is that team?  All our people are too busy – in fact we are leaving revenue on the table as we do not have sufficient engineering hands!

What is the solution for this conundrum?  Should you or should you not reengineer?  Here are some factors to consider:

1) Distinguish between being “occupied” and being “busy”

Are your engineers running from pillar to post on issues that are all related to the design of your software?  They are perpetually busy, fixing old problems and hence there is no value add to your product?

2) Think and define a Product Roadmap

More often than not, putting all the improvement ideas in the form of a product roadmap and fixing definite deadlines for releases and feature-sets of releases will fix the issue.  Sounds simple, right?  For those of you who manage it this way, it will sound too simple.  But, for a whole load of others, it will be best said and not done.

3) Think outside your internal resources a.k.a outsource

Absolutely!  If you ask internal guys, they say they are busy.  But, think beyond and look at long term.  After all, beg, borrow, steal – in short, be aggressive is the way for success in this age.

4) Is there real profitability?

More often than not, you will not clearly analyze profits in each customer instance, and that may end up as a sticker shock.  May be 80% of actual profits are hidden in 20% of the work that you do, and time to eliminate the remaining 80%.

5) Get external consultants

Many will scoff at me for writing this.  The reputation of consultants is such.  But, there is real value in consulting with people who interact with multiple companies that go though similar situations.

ASP Vs SaaS difference

ASP Vs SaaS:  What is the difference?

These terms are often used interchangeably…

Maxine Kincora (http://searchcio.techtarget.com/tip/0,289483,sid19_gci1216679,00.html?track=NL-453&ad=565552HOUSE&asrc=EM_NLT_560538) has tried to clarify the differentiation. 

She says – ASP means multiple enterprise software from different vendors sold and serviced by a data center – like USi or OpSource.  And, SaaS means, the same application served in the same style, may be in the same data center hosted by USi, but sold by the vendor.

Whether I agree with it or not, it is certainly a good try!

In any case, ASP or SaaS are all only semantics.  Reality is that the business model of distributed computing is a powerful, unstoppable phenomenon.

India versus China-why not US versus UK?

New magazine on outsourcing in the block – BPO Market Watch carried an interview with Pramod Bhasin, the outsourcing pioneer.  (August 2006 issue)  Very logical question – Is China going to beat India in outsourcing?

He asks why are we asking this question?  Why are we not asking US vs UK or Germany or whatever?    He says that it will be complementary.  All will co-exist. 

How true!

In this world, not many new things have completely removed or replaced the old things. 

One species may have a small disadvantage compared to another species for a short time – an environmental correction takes place – but, the eco-balance ensues, invariably.

Look at many trains in NY, you find the old-fashioned ticket collectors coming and punching tickets at every station.  That happening in the Big Apple, the world’s economic capital, is something unbelievable, but the ecosystem lets things co-exist.  A new thing does not completely eliminate old style. Else, why would Amazon open physical stores after its online success.

I also believe that all of these new countries in the block will have their fair share of the outsourcing market.  We may have some job-losses in India due to this second level outsourcing wave, but majority of the businesses in India will find some alternative to survive and build a niche – the most sensible of it is to go and setup operations in these emerging centers.

Why I want to set up a captive center – An ISV’s perspective

It was interesting.  The very next day of my meeting with this country head of the  Captive Centre, I met this other man who has setup and been running an offshore “outsourcing” operation for a mid-sized ISV since last year.

They had started with 10 people and have grown their relationship to 70 people.  He was mentioning that he is pretty happy with this outsourcing company based out of Hyderabad.  (We had bid for this project and lost.  To our credit, he was mentioning that he was very impressed with Aspire Systems, but the infrastructure that time was a huge drag.  He said, if he were evaluating companies now, he most likely would have chosen Aspire what with the new infrastructure.  The very fact that he made a special trip to Chennai just to meet with myself and Gowri showed us that he meant it.)

He was saying that he had been and is continuing to advise his company to go captive in India.  His arguments were pretty valid.  While it is a disadvantage for me to mention those points given where we are in our business, it is only fair for me to share what I heard.

He was saying that the relationship is likely to grow to 200 people or more.  What that means is that the economics of scale will be building quickly.  While there are arguments about when a captive centre becomes viable, (500 or 1000 people is the usual advise) his perception was that it will be viable when they become 200.  He was also mentioning that all his company has to do is to hire somebody like me or Gowri who have experience in running an offshore operation, to eliminate the problems associated with outsourcing.

He was saying that to lock such a huge percentage of their critical development operation to the fortunes or misfortunes of another company is looking risky for him.  What control do we have if this company goes belly up or gets acquired or changes business direction etc?  That was his question.

With due credit to his opinions I have some arguments that favor companies like us.  We have a business model that is non-conflicting with our customers.  We have a sound business plan that is very long-term oriented.  We don’t plan to change business direction or go belly up.  Going by our stability for the last 10 years in highs and lows, it is natural to expect that we should be there.

Moreover the kind of risks he talks about is not “non-existent” in a captive Centre.  In this age of mass exodus and two digit attrition nobody can feel safe about any such thing.

This person who is a very smart executive is feeling a little bit constrained that his company is not allowing him to set up a captive unit.  In any case, he was mentioning that he has B. O. T. clauses built into his contract.  So it appears like he is indeed safeguarded against such mishaps, isn’t it?

Captive centre economics – my recent discoveries! – Part II

In continuation of my earlier post on the same subject… 

In addition to the real estate costs being much higher than what we encounter, this captive centre also had other things that drove the costs higher.

She was mentioning about some 20 people out of these 40 people team to be mission-critical for her.  If we were running the development operation for this company, we would have had at the maximum, 10 critical people, and would have set up processes that ensures that 40 people output  comes about with these 10 people and the 30 other “change-able” people.  (Do we want stability?  Absolutely!  Do we think the other members are non-critical?  Of course, not!  But, that is the reality and a business model for offshore operations of a mature company.)

What does that mean to the economics of scale?  If we had to pay 2X salaries to the critical people, the total cost for the said Captive Centre will be 20 x 2X + 20 x 1X.  That would be 60X for 40 people.  So, average salary for them is 1.5X.

In our case, with the same logic, it would be 10 x 2X + 30 x X = 50X.  So, our costs would be 1.25X.

See how this makes a difference?  Scale matters!

Can they possibly do the same as what we do? Not possible by any count.  We have more than 200 engineers.  So, we can quickly substitute for any loss / change in the other 30 people.  They cannot, possibly.  Scale matters!

Add to this, the cost of the bench.  We typically maintain 20 to 25% Bench.  Bench contains trainees, new joinees and the like.  Obviously that must be happening for the Captive Centre as well.  If we assume 25% bench for this captive centre, their salaries are 60 X for a 30 people output.  That means their salary per person-month is 2X.

That is what they will typically pay for an outsourcing company as fees per person-month.  The outsourcing company manages to make a 25 to 30% profit out of this.  That is precisely the power of scale.

I am positive that there are advantages why software vendors setup their captive centres.  I will write about my interactions with another customer in a later piece.

Captive centre economics – my recent discoveries!

Last week I met with the country head of a local captive center for a mid-sized ISV from Texas. While I have always known that captive centers with smaller scale makes it expensive, I learnt a little bit more of details in this meeeting.

Since they also operate in India a normal assumption would be that their cost should be similar to ours. But, the opposite is true.

 

One striking difference was the way they had set up the infrastructure. I had realised based on our own experience with respect to setting up our new infrastructure that “scale” matters. We had always operated in tight spaces. Just last year we had a total of 6300 square feet of rented area. We had 100+ people working. That made the average square feet per person to be about 63 square feet or less. Real estate, assumed to be lower in cost in India or at least equivalent in cost, in reality, adds up quickly.

 

When we built our first phase, and moved in, we only had about 170 people. And we had built a 45,000 square feet of space. That made the built-up space per person to be about 300 square feet. It may appear insignificant but in reality this very thing has made a significant impact in our bottom line for the financial year 2005-2006 – much reduced profitability for that year for us.

 

This lady who is the country head of the captive centre that was employing 41 people in North India, mentioned that the area of their office was 17,000 square feet. That naturally made her per-person square feet more than 400. No wonder, their costs were phenomenally higher.

 

In setting up a development or B. P. O. in India, the only cost is not the cost of labour. Cost of labour may be cheaper by direct terms, but the other costs become significant. One such cost is real estate. Surprisingly, costs of real estate in India many times exceeds that of the United States. $1.5 to $2 per square feet per month is normal. At a per person square feet of 400, that works out to $600 – $800 per person per month. See how quickly this adds up? See how this makes the labour cost savings vanish in a jifffy? Scale matters!

 

Picture this: the space in India becomes a lot more expensive, due to the additional infrastructure needs that have to be set up in India. She was mentioning that when she had set this up initially, her executive members in the United States could not understand why she needs a UPS for a normal, non mission-critical operation. Why need a diesel generator on top of that? But that is reality in India. The loaded square feet cost is even higher than the $1.5 to $2.

 

So, what is the solution? Scale, scale, scale! In our own case as we have become about 270 people our per-person square feet has reduced to about 150 square feet. When we build our next phase of 23,000 square feet, and the grow to 500 people, per person square feet will even reduce further. Scale matters!

 

No wonder, people talk about scale as an absolute need to justify an offshore operation.

 

The higher costs did not just stop at real estate. More factors were influencing their economics of scale and were rising their costs. I will write about them later.