Skip to Content

It’s called BPO. Part-I.

This is repost of my private blog that hopefully can give birth to a discussion at SDN too.

I ran across the BPO (business process outsourcing) term in recently found  blog of Vinnie Mirchandani (very interesting and fertile in ideas blog). I thought it’s called out-tasking or out-servicing but actually it doesn’t matter. Vinnie has written a few articles about BPO and covers this field broadly and I’d like to add my two cents here too.

Roughly applying the principle “Shoemaker, stick to your last” to the businesses where IT plays a noticeable role one might assume that their ITs shouldn’t be large in numbers (either of people or direct expenses). But in reality it’s not true, of course. I incline to agree with Vinnie in his foreseeing the future of successful enterprises as those that out-task their not core business processes. I’m sure the current situation where every enterprise invites the wheel exists due to the ‘historical reasons’. I think also that in every enterprise a very limited number of processes represents ones that actually core for the company. The rest is severely universal and repeats itself from one company to another. The idea of BPO is to take such non-core services out of direct control and instead of managing them just to consume from an outside service provider.

Now a tough moment here is to distinguish between outsourcing and BPO. Typically by outsourcing we mean out-contracting. So you define what results you want to get and a contractor is obliged to implement it (in our case to develop software with some level of maintenance and suppurate). The problem with outsourcing is to define what you want. Many unsuccessful outsourced projects failed because the customer didn’t (or couldn’t) define and transfer in a formal form its requirements. Then the contractor formally carried out what the agreement was about but in fact it didn’t make the customer happy and satisfied.  There were also some unsuccessful experiments when entire organization liquidated their internal IT group and entrusted with the work an external (outsourcing) contractor to define, design, and deploy necessary solutions. Here the reason of failure is similar to the previous case.  The implementator created something that didn’t fit the customer’s needs.

So what the BPO is different from pure software development outsourcing? A customer in this case doesn’t order an implementation but buys services. Moreover, the quality, in its widest meaning: the feature set, the price, agility to changes, performance, support and so forth, is higher than if it were developed and deployed by the customer inside the enterprise.  For a BPO provider this service is his core business and hence he is an expert and knows more about it than the customer. Such differentiation should allow him to offer services more appealing to the customers comparing to theirs developed in-house. At the end of the day both win: the customer from lowering TCO and the provider from selling services.

I’m not saying that ALL enterprise processes can and should be outsourced via BPO but I guess that a major portion can and should. I think we don’t witness a trend toward BPO merely due to inertia and the fact that  BPO is still new. Only early adopters gingerly try to outsource via BPO some not key processes to see the results. A small number of BPO providers of heavy enterprise services (like HR, SCM, CRM, ERP or finance) also doesn’t promote this idea. But the global “service-sation” in various incarnations (SOA, ESA, on-demand services) of internally deployed systems firmly prepares enterprise architectures to be ready to outsource any of their parts. Actually ANY service can be out-serviced and the good think is ANY PART of a service can be independently outsourced too.

In the next blog I’ll bring some concrete examples that came to my mind that my look more attractive for enterprises to consume than to develop.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.