Friday, May 24, 2013

Having worked in the world of CRM since the mid-late 1990's sometimes I stop and look back at how things have evolved. I remember having to explain to people what "CRM" actually meant. Today most people understand that CRM stands for Customer Relationship Management, but most outside of the CRM consulting world, still think that CRM is just software, but I will save that topic for a future blog.  Although the term "CRM" really only came about in the 1980's, the concept of a Customer Relationship System, at least in terms of computing, goes back to the late 60's and early 70's- its just no one knew it was CRM. In fact, most companies were not interested in catering to their customers. If they leave, we''ll just get new customers was the prevailing attitude. Due to the high volume of transactions and customer interaction, Phone companies and Banks were the earliest to use "CRM", although  they don't resemble anything like CRM platforms of today and they certainly were not called CRM.
For example, phone companies had large air conditioned cooling rooms, with rows and rows of mainframe computers utilizing punch cards and later, reel to reel tape, to run the software needed to keep the company running.  These primal and unsophisticated mainframes ( some of which still exist today!) tracked information about their customers. Where they lived, their phone numbers, invoices, payments made, and yes even some basic customer service. Sales would get reports, although infrequently, they still got them. Marketing could access the data printouts to understand trends - but it was all manual analysis as there was no thing as spreadsheets or business intelligence software. In the 1980's, ATM's became more popular - this was one of the first "self serve" customer portals and was an extension of the banks mainframe. Customers also realized they had choices when it came to the products they bought and consumed and companies started to realize that the full sales equation  which was to understand your customer's wants and desires, but also to give better customer service and RETAIN customers.
Now things have certainly changed over the years - ACT! came on the scene in 1985 and was called "contact management" software and sales organizations gobbled it up. Then with the advent of client server architecture, the power of computing to help drive sales and marketing really started to be understood.
Siebel, Pivotal, Saleslogix, Onyx, Peoplesoft, Oracle, Microsoft, Salesforce.com are just a few of the names that have come ( and gone) over the years. The hardware and software has advanced at lightening speed, as well as all the infrastructure  needed to capitalize,  like broadband internet and smartphone technology.
Watching Star Trek as a kid, I remember thinking the computer on the USS Enterprise was the coolest thing - all Captain Kirk or Mr Spock had to do was ask it a question and INSTANTLY they had their answer. The communicator they used was something any boy my age craved.  And we have these things now today.
However, they way we implement CRM Software systems regardless of whether in the cloud or on premise, really has not changed. Yes, we can call it "waterfall" or "agile" methodology - I assure you there will be new names in the future to describe some other supposed "new" methodology - but the basics have not changed one bit. Let me explain. Recently I had a conversation with my father, who also did the same thing as me for a living before he retired. He was a project manager at a large pharmaceutical company from the late 60's until he retired in the late 1990's. He worked in the IT department and was director level when he retired. However he did not start out working with software and computers. He graduated from engineering school in the early 60's and was a mechanical engineer. Now in those days there was no such thing as studying computer science in college. It did not exist. With the advent of the computer age in the 60's now there was a need for people to program them, but where do you find people that can code assembler, COBOL, JCL and the like? You go out and find smart engineers. And thats by and large what happened. My father was lured away from his well paying job, to work in a career that no one ever heard of. Software ? The word was being bandied around NASA and other high tech places and the laughter could be heard from cocktail parties around the country. "Your husband is a SOFTWARE PROGRAMMER"????  There was no agile or scrum or waterfall methodologies. No PMP certification, no IT Governance, no change management.
What ended up happening is, these smart engineers figured out that they had to understand what the business people wanted the software to do, then see if the software could do it. Traditionally we call this Requirements or Discovery or GAP Analysis and it still exists in one form or another regardless of the methodology. Then they would figure out exactly what the software would do. They would create process flows of current processes and then what the new processes would look like. In fact, the practice of using process flows comes from what engineers learn in college from day one, so they transferred that skill over to software. They would make up hand drawn screen mock ups and run them by the biz folks for approval. Lots and lots of meetings and workshops. We call this design or prototyping. Then they would go and code the software, each programmer testing or unit testing his own work. Then when the programmers felt that that it could be tested by users, they would bring in the business people to really give it a good shake down. They would find "bugs" ( a term that was actually termed at the advent of the computer age when a real bug shorted out a computer circuit and a new term was born) and fix the code and retest. User training was organized. According to my father, who became a project manager in short order, he felt a very real need to practice MBWA. MBWA? "Whats that?" I asked him. "Management by walking around" was his answer. You see, he would walk around and visit his business side customers, the ones who would be using the software his team was working on, so that he could get their feedback, get the word out about whats coming and how important it would be for their departments support, as well as all the benefits the new system will provide for them. Hmmm - sounds like change management to me. He clearly understood the value of working with the business, and having them on your side.
There have been lessons learned over the year. We are all much smarter on how to implement CRM. We fully understand the value of change management, project management, following best practices for project management, and many more lessons.
But other than the technology, not much else has changed. People still go to work. They still want to have their jobs go smoothly, and be more efficient. Software requirements still need to be gathered, prioritized, GAPs understood, designs done and validated by the business folk, user testing, training  - its all the same today as it was back then. None of this stuff existed in any formal way back then - people like my father used their common sense and figured it out as they went along, with out the benefit of reading a book, or Wikipedia or even a blog like this one. Pretty amazing when you think about it.