| Page 2 of Page 2

Series on CRM

July 8, 2012February 4, 2017 Prasad AjinkyaLeave a comment

Today, I sat down and started writing a post on Customer Relationship Management (CRM) implementations and it’s failures in most organizations.

The idea came to me as I was reading one of Andrew McAfee’s posts on his blog, the business Impact of IT. In case if you do not know about Andrew McAfee, you can read up on his blog at HBR.

There have been many theories and reasons on how to start implementing a CRM and what are the typical pitfalls. If you search for this on Google there will be pages on pages of do’s and don’ts. Of these I have read a good number, however theory as always is so vastly different from practice that when you are on the ground, it becomes difficult to relate (and subsequently apply) theory to real life problems.

I consider the CRM implementation at Pristine a failure. It’s not fully implemented yet, and its not fully being used as well … but those are precise points why I consider it a failure. I was intending to write a piece on this on my blog.

As I kept on writing relating my experiences with the implementation, adoption and failures of CRM systems, I realized that one post won’t do justice to this (I had touched around 1000+ words and there was room left for more!) and decided to split this into a series of posts.

~~In the next few weeks, I will keep writing regular posts on the CRM system at Pristine and how it has failed … and how it can be revitalized.~~

Updating this post after 5 years, the CRM system we installed has been a resounding success and a continuous source of business insights for the organization.

The Parity Bit

February 22, 2011February 4, 2017 Prasad Ajinkya4 Comments

Here’s an interesting mind bender for you (do note that this question is used in a lot of job interviews) –

A warlord has captured 1000 villagers, and has decided to put their wits to test. He has put 4 different coloured hats (say Red, Blue, Black and White) on these thousand villagers and arranged them randomly in a long queue. The arrangement of this queue is such that each villager can see all the villager’s hats in front of him, but he cannot see the villagers behind him.

Each of them now have to guess what colour their hat is. If it is the right colour then the villager is allowed to live and is freed, if not … then let’s just say he won’t be having any more headaches.

The villagers are allowed to discuss as a group to decide on a protocol (an algorithm of sorts) to decide how to call the colours so that the maximum no. of villagers survive. What is this algorithm and how many villagers will survive?

Hint: The title of the post

Taken from Wikipedia,

A parity bit is a bit that is added to ensure that the number of bits with the value one in a set of bits is even or odd. Parity bits are used as the simplest form of error detecting code.

The villagers have to use the concept of parity in their answers. Instead of taking a guess at what colour his hat is, the last villager is the parity bit. His answer gives an indication to everyone else in the queue as to what could be their colours. How? Here is so –

Each colour is denoted a no. (Red=1, Blue=2, Black=3, White=4). Since the last man can see all the hats in front of him, he takes a total of all the number before him and does an operation (total mod 4). This is the parity (or the error-correction answer). Now the man in front of him can see all the hats (except his of course) and also knows this value error-correction value. What he has to do is do the same operation for all the hats in front of him, and subtract that value from the previous mod. That’s the colour of his hat.

The cool thing about this is that even if there is one fool of a villager who miscalculates, the villager next to him can detect this error and can correct it immediately.

Now, where would we be using this? (In other words, why did I bother with this problem?)

Networks! Computer networks use the concept of parity bit to detect transmission errors for quite some time now (have you ever faced that pesky CRC error? That’s your parity bit right there).

Intensity of technology adoption

February 16, 2011February 10, 2017 Prasad Ajinkya4 Comments

Everybody you know, will probably agree with this, that Technology can be a great enabler.

It’s one of those motherhood statements (like “Shit happens” or “Life sucks”) that arguably can’t be denied. As someone who has often taken upon himself to forge this enablement with the demands of the business, I want to take a different stand.

Technology CAN be an enabler, only if you possess the know-how of implementation and your audience possesses the temerity to bear the brunt of teething and adoption problems, then can it be an enabler. How many cases have we seen that an organization wide technology upgrade has failed simply because the intended audience does not adopt it, but merely reverts to the easily available alternative.

My mother heads the medical department of State Bank of India, she in fact is the Chief Medical Officer. She tells me that they had tried three times to implement some form of an enterprise system for their department, Each time it had failed. Why did it fail? Not because the implementation was incorrect. We can’t say that, the moment we do – the implementation partner will pull out the requirements sheet, the scope document or some form of agreement which indicates that there was no breach of contract from their side.

And that is the problem I want to point out. Technology is not a function which can run in a silo. It permeates through the organization, from the most mundane of activities like checking email, to most complex of them like implementing a Decision Support System to help the top brass in strategic decision making.

Technology adoption therefore has to be intense. So intense that it should change the identity of the organization. If done properly, it can vault the firm into the next level.

The next time someone tells me that technology CAN be a great enabler, I will tell them that if my aunt had a moustache, then she CAN be my uncle.

1984 to 2010

December 6, 2010May 6, 2018 Prasad Ajinkya6 Comments

We are in the process of formalizing our IT and Electronic Access Policies. In this process, often the team drafting the initial proposal finds it pretty easy to switch to the Orwellian mode of 1984, wherein Big Brother is always watching.

Although the intent of these people often stems from the fact that they desire to protect both the system and it’s users, but that sometimes requires that extra bit of control. However, it becomes extremely difficult to tell the need for control from genuine to paranoia.

Further, due to some unforeseen events happening in the recent past, these rules are doubly strict ensuring that the past mistakes of a few have to be borne by the entire team. Only to ensure that something that happens out of the blue should not happen again (and rightly so!).

The problem at hand is how to ensure that people are enabled to work and co-create with each other, but are still protected from any malicious ill will that might exist outside (and even within the system). How can Big Brother start co-operating instead of watching?

One clear method is to assume that all people are good and need to be enabled. The other is to work closely with them step-by-step and layout a simplified process and get the end-user buy-in on each of the steps. Till that happens, Big Brother will continue to exist … we are watching you!