Rage Frameworks' Venkat Srinivasan: 'The BPO Market Is Not Sustainable in the Long Run'
Published: December 17, 2009 in India Knowledge@Wharton
"There is automation, and then there isautomation," says Venkat Srinivasan, co-founder and CEO of Rage Frameworks, a Massachusetts-based startup whose technology he claims will radically change the way companies manage business processes. Rather than investing in outsourcing or business process management tools, Srinivasan -- a New Delhi-raised serial entrepreneur -- says companies now need to move up the evolutionary scale and embrace automation that lets them segment and change the way they work with hyper speed and efficiency. But is business process automation -- or BPA -- simply adding to the alphabet soup of tech jargon?
The following is an edited transcript of Srinivasan's recent interview with India Knowledge@Wharton.
India Knowledge@Wharton: Could you explain the differences between business process automation (BPA), business process management (BPM) and business process outsourcing (BPO)? Because the acronyms are so similar, it's easy for people to confuse the three. And specifically, what is going on in the BPA market in which Rage Frameworks plays?
Venkat Srinivasan: We are constantly trying to do a better job of [explaining the differences] on our website and in our presentations. The way we define and practice BPA makes it a new category. There is no well-established BPA market. It is a market that we are, in some ways, creating. Having said that, let's parse those three items separately.
Business process outsourcing, or BPO ... is based on cost arbitrage, with players who are in low-cost locations around the world that shift the burden of work [from one location to another to take advantage of lower costs]. Everyone understands this is basic BPO. You are throwing bodies at a problem. About 10 years ago, that certainly was an attractive proposition for companies. Therefore, we have a large BPO market today, which is still growing at double-digit rates. At Rage Frameworks, our view is that the BPO market is not sustainable in the long run. That market has to evolve.
There are several factors that make cost arbitrage evaporate over time. First, the "pop" you get from cost arbitrage is one-off. Let's say you transfer a business process to India. You lower your costs by a third, but then that's it. The second factor is that costs in the low-cost locations will rise. It's the basic forces of demand and supply. There is now significant wage inflation in India. The "pop" you got in the first year is going to be whittled down, because you have 20% to 30% wage increases each year. (That is a good thing for people in India.)
If you play this out for five years, the cost differential isn't going to be as much as it was when you shifted the work overseas. It will probably never be equal. Otherwise, there would be no reason to go. But when you add up all the other issues that go with it, BPO becomes unsustainable in the long term. Companies currently relying on BPO will have to evolve to a different model.
India Knowledge@Wharton: Are you suggesting that business process automation is part of the evolution of BPO?
Srinivasan: That's right. It's where both BPO and BPM have to end up. The other issue with BPO is that you don't get to a better place with it. Most BPO companies today promise their clients that they will improve processes. However, throwing bodies at the problem gives you, at best, some basic technology solutions. All the BPO business models tend to be "body" driven; pricing is the number of bodies multiplied by the cost per body and there is very little incentive to improve processes.
India Knowledge@Wharton: In that traditional BPO model, no customer is going to get the scale they need.
Srinivasan: Yes, scale, as well as process improvement. Businesses are ultimately interested in improving their processes. As you scale up, different problems emerge. As new business trends and needs in the market arise, your business processes need to change. With BPO, a customer doesn't get any flexibility in execution. You get only lower cost with BPO. At Rage, we have large, global clients, and many of them are big BPO users. They are very frustrated. It is obvious that in moving the market toward BPA, these firms clearly recognize that shipping 700 jobs to Malaysia to lower costs isn't necessarily better in the long term.
India Knowledge@Wharton: Now let's look at business process management.
Srinivasan: The operative letter here is the M. BPM is largely a set of software providers, who have evolved from the days of Six Sigma and reengineering.... If you look at a typical large enterprise, there are a plethora of business process challenges. There is no systematic institutionalization of their processes. When things get to a head, somebody says, "Either call in Six Sigma-qualified consultants or get somebody to help us reengineer our process." ....Generally, the company has an intimate idea of what it does on a day-to-day basis, but there is no holistic view of the process. Without that view, you can't attempt to figure out how to do things differently. The consultants provide that value.
....A primitive form of BPM is a flow-chart tool. Today, BPM vendors are more sophisticated. They allow you to document, manage and measure processes. Then you take the processes and go to a technology-services company and say, "Here are our current processes and here are the processes we want. Can you help us implement [the change]?" The next generation of BPM vendors has moved into facilitating implementation. Several tools now generate code to implement business processes. That's where the big differentiation is between what they do and we do with BPA.
There are several issues with the current generation of BPM tools. You don't solve the age-old problem of time-to-market. By the time this technology is built for your new process, the process is outdated. It is of no use. It still takes a long time to implement.
India Knowledge@Wharton: Processes are constantly evolving.
Srinivasan: Exactly. It is never-ending. The entire essence of BPM is to increase agility. Some firms talk about their "agile" BPM methodology. While it is more agile than before, it still takes a long time, and because its implementation is still done in a conventional paradigm by generating code, that solution is often outdated. This generates frustration at large, global institutions.
Let's go on to the way we practice BPA. An acronym such as BPA doesn't do justice to what we do.... Let's think about how conventional software development life cycle (SDLC) works. You have an idea. You take the idea and expand it into a set of requirements. Then you design it and your development team codes it. You test it and you release it.
Technology development, over the years, has come a long way. However, the focus has been on tools to help achieve more consistency and faster throughput. Twenty years ago, technology execution was a big [issue], but the problems were reliability and consistency, as was coding and programming. We focused on whether you were a good programmer or a bad programmer. Today, countless firms are good at basic programming. Good programming is fast becoming a commodity. I don't want to trivialize the value of good programming or engineering, but there are lots of CMM Level 3+ firms out there. They do a great job of giving you consistency and reliability. That issue has been largely resolved.
The issues that have not been resolved is time-to-market and flexibility. When you go through SDLC, you take a company's business description and translate it into a machine-readable description. The translations don't add any additional value. The idea is still your idea, but to get it to work requires the translations, and they take time and are of no practical value. If you could implement your business idea without programming, why would you not do it?
Rage has created a technology platform where -- instead of a forward engineering-oriented lifecycle going from an idea to release in a clockwise cycle -- we have eliminated many steps by creating an abstract engine that understands the idea of software development.
India Knowledge@Wharton: Can you share an example?
Srinivasan: A 100-year-old global financial institution needs to roll out a new credit card. It knows exactly what it wants to do in terms of a process to evaluate an applicant and issue, reject or price a credit card properly. This is the business process. [But] with millions of applicants, [the process] not scalable without technology. The firm estimates that -- even with BPM tools -- it would take 18 months to roll out the new credit card.
India Knowledge@Wharton: And this is in a very experienced firm. No other firm would be able to do it faster?
Srinivasan: That's right. In this case, there is no physical product. The process is its product. It evaluates your risk and then calculates what level of risk it is willing to take and how to price the card. We did this for them in two weeks, not 18 months. This is not a hypothetical case. I can give you lots of examples like this, even within the same institution. It is endemic of all such institutions because conventional SDLC and BPM tools work at a low level of granularity and documentation alone is going to take two or three months.
Let's take the credit card case and drill deeper. Why were we able to do this in such a short span of time? Rage's framework has a series of abstract components. It is like Lego, but these Legos are highly "morphable."
Let me break this particular process into three steps. Step one is to gather information from internal and external sources about the credit card applicant, which could be around 10 sources. It is a big step with conventional technology, because it requires you connect to multiple sources. In step two, you normalize the data. You need to "flatten" the information to get a sense of what someone's profile looks like. You need to apply a series of rules on the data. Most companies won't blindly use the score from [credit-check company] Fair Isaac to assess risk. They'll also use rules of their own.
The third step is to determine the outcome. Rarely does the firm say "yes" or "no." A decision in this context is a continuum. There is "yes" and "no" on the two extremes and then a bunch of pricing decisions in the middle. For example, the system may add 200 basis points to the interest rate on an applicant's credit card depending on the risk.
The fourth step is issuing the cards. This is the easiest step, as the firm is well established. It can issue a million cards an hour. But the first three steps are very hard because they have to be done with legacy systems and have to integrate many external sources.
To accomplish step one, we use an abstract component at Rage called the Connector Factory. There is no programming required. Instead, we type the structure of the information from the first source, we go to the second source and do the same thing, and so on.
There are very important ideas in what we do at Rage and the acronyms might make people put us in the same bucket [as BPO and BPM]. That's our toughest challenge. We create mission-critical technology implementations without programming. In technology terms, we have created a very sophisticated abstract platform using a highly model-driven architecture. But more importantly, going back to SDLC, we leave your business processes as high-level models. From a layman's point of view, we are a live solution that can be modified at any time....
Your flow charts are still there. But if you are driving to work and you get a new idea, you can pull up the flow chart, modify it, save it and it's ready to go. It is live.
Rational Rose, a big product that IBM owns now, takes eight months to finish modeling because you have to go to a very low level of programming constructs. Rage does the modeling at a high level and reduces the logic to data. It's very abstract. BPA is the best acronym we could come up with.
India Knowledge@Wharton: Is what you are doing at Rage informed by one of your earlier companies, eCredit.com, a real-time credit services for e-business?
Srinivasan: This dates back to my doctoral thesis and work as a consultant. [With an interest] in and around time-to-market, I was primarily a finance guy with expert systems and artificial intelligence to support human decision-making. This is just one big evolution for me. I started out by asking: "How do I 'operationalize' flexible decision-making applications or use of technology in the credit decision-making context?"
India Knowledge@Wharton: In the credit-making context, with eCredit?
Srinivasan: That was the original idea, but one thing led to another and in those days I invented whatever I couldn't find. That was in the days before Windows. We didn't have graphic user interfaces. Then I ended up doing a lot of stuff on the Mac because that was the first graphic user interface available....
India Knowledge@Wharton: Why don't the big institutions automate all their business processes? Is there risk involved? It seems there is a cost advantage.
Srinivasan: Our guys were at a recent conference organized by a financial institution for its global supplier base. These people have more than 300 or 400 global vendors providing BPO services. The theme of the conference was automation. People very clearly have moved from BPO to BPM.
Our point at the conference was, "There is automation and then there is automation." There is automation that is going to become legacy the moment you finish. That is not the automation you want. You want automation that is going to be flexible and let you adapt to changes.
Rage is a tiny player. We are the new kid on the block. We are promoting flexible automation....
India Knowledge@Wharton: It sounds as if part of your challenge is to stimulate that market.
Srinivasan: Exactly.
India Knowledge@Wharton: Is there a BPA application for, say, financial regulators or people looking at health care costs or energy markets?
Srinivasan: Every business is a collection of business processes. It doesn't matter what field you are in. Our [job] is to look at every task and think about how to create an abstract component that can help somebody automate the task in an intelligent, flexible manner.
Most work models today are centered on individuals. Companies are interested in leveraging technology in an intelligent manner. Rage has knowledge-based components -- rules, decision trees, computational expressions, natural language processing, etc. The point is not about automation. Rather, from a business point of view. The point is about scalability....
Today, the general work model is centered on an individual. What do we do when we go from 15 to 100 individuals? We write a policy manual. We write procedures. Why can't we just automate it?.... Generally, you automate the stuff that is well understood and not going to change. The moment some aspect of your process has dynamic characteristics, you struggle. This is where conventional automation pigeon holes the business process and says, "We just can't scale if we try to accommodate the dynamic aspects. We are not going to automate it."
....As you grow, you should institutionalize processes so you're not relying on someone to remember what the process is. That way if an individual enters the process only if the individual is required to execute a task. But today, process memory is in the minds of an individual and not institutionalized anywhere. Rage is attempting to provide a framework for institutionalizing business processes.
India Knowledge@Wharton: How did Rage decide to incubate and spin off or nurture other companies? Your firm is very lean. How did it come up with the bandwidth to do the other stuff?
Srinivasan: I wanted to do this within eCredit. The idea was very simple. We felt that our technology was applicable in many areas.
India Knowledge@Wharton: So you built different verticals?
Srinivasan: Precisely. We launched individual subsidiaries because we thought it was a pragmatic way of scaling them when external financing was needed.
India Knowledge@Wharton: How critical is the proprietary nature of what Rage is offering? How important is intellectual property?
Srinivasan: It is important. We probably have a 24-month lead as a first mover. Having said that, we are continually trying to protect our IP rights by applying for patents.
India Knowledge@Wharton: I am curious about your stint with the consultants Bain as an "entrepreneur in residence." How did this happen?
Srinivasan: Bain was the seed investor in eCredit. I have had a long relationship with Bain. When I came out of eCredit, I wanted to do Rage. Bain was, at that time, starting up its venture funds again and offered me an opportunity to come in while I was still formulating Rage to help get the funds going. They already had the venture fund and a very good team ... but I helped with due diligence and investing in technology start-ups.
India Knowledge@Wharton: When did you decide to leave academia and get dirt under your fingernails? Did you wake up one day and say, "OK, that's enough" or had it been building for a while?
Srinivasan: It wasn't a sudden wake-up call. When I look back, it seems very premeditated, even though it wasn't. Fundamentally, I am a creator.
Even in the academic world, I spent a lot of time doing research. That was the outlet for my creativity. Then I got involved in consulting assignments with Fortune 500 firms. In these assignments, I realized that what these guys really need is a software product. I looked at all the "decisioning" variability in these groups and try to figure out how to institutionalize credit policy.
I began doing "skunkworks" projects [or quick projects developed by small groups of people] in [a] spare bedroom. I would show them to somebody and they would find it interesting. I kept iterating. Finally, I had something that could be used. Apple was the primary catalyst. In my sabbatical year, I decided that I was going to continue in my academic role and kill this project or I was going to give up academia and start a company. I had to do one thing or the other.
India Knowledge@Wharton: How have your roots played a part in that story?
Srinivasan: One is problem-solving. My path through my professional career -- and even through school -- was somewhat skewed toward problem-solving. I always had an opportunity to solve difficult problems. I used to work for Union Carbide in India, where there were lots of challenging problems. I was also determined to make things work. When I started eCredit, the credit managers of many companies didn't believe that our vision of creating a knowledge-based application would ever happen.
In India, we had to work with very little. I grew up in a middle-class family. In school, I used to play badminton -- I still do. We didn't have any courts, so we created our own court. We just invented what we didn't have. I'm sure there are hundreds of thousands of millions of stories like this. For me, at a minimum, it created a sense of confidence and determination.
[Then there's] repetition. My kids have gone through school in the U.S. and I see a lot of benefits in their education. They are growing up to be well rounded and wanting to learn. When I was growing up, we were never encouraged to ask "Why?" In fact, I was punished in class if I did. One benefit of that system, however, is that it instills high levels of concentration. All I did was repetition. I remember spending two hours after school every day solving math problems. That's it. That's all we did. We solved math and accounting problems and we were timed. Such repetition sharpens your focus and concentration. We had no alternative.
India Knowledge@Wharton: How have you been able to interact with the Indian diaspora in the Boston community?
Srinivasan: Two things have helped. One is the Indian diaspora and the other is Bain. Both groups have always encouraged me. I have known Bain for almost 20 years, back when it was a very small firm. In the Indian diaspora, I have lots of friends and I am on the board of TiE-Boston [a global non-profit promoting entreprenurship].... I'm very involved with TiE Boston, and we mentor young entrepreneurs [and] I'm involved with the American India Foundation. We support Indian [non-governmental organizations] on a large scale. AIF is more about giving back to India whereas TiE is more local.
Compiled and Adapted from
http://knowledge.wharton.upenn.edu/india/article.cfm;jsessionid=a830cf09b72442ad81c76a66141d26265f4a?articleid=4435
And brought to you by
Navneet Singh Chauhan.
