A professional acquaintance and an expert in statistics once told me that if you don't understand how to perform the process of analytics through programming - the creation of the data flow, the transformation of the variables and the development of the statistical procedure - then you had no business performing analytics. At this person’s particular company, the goal was to increase the analytic competency of the organization – in Tom Davenport parlance, “Compete on Analytics.” Over time, this company would be rolling out training for analytic methods and technology training to a wider class of business analysts.
Which begs the question: Do we lose something when we stop coding an analytic process and start using point-and-click applications? Is there something about programming analytics that makes the analysis more valuable? In a way, I understand this person’s argument because there is a beauty, elegance and intimacy of the analytic process - programming will give you a greater understanding of the data and the analytics, and for those of us who like to code, there's the sheer enjoyment of it! Needless to say, this person was not a fan of menu-driven applications and was instituting a "back to coding" approach in their analytic initiative, regardless of whether the user was a hard core statistician or a beginner business analyst.
Is this initiative doomed to fail? First of all, virtually every major provider of analytic software (SAS included) is developing their software for a wider class of non-techincal, but analytically minded people (hence the term “business analytics”). Being free from learning complex programming languages allows users to focus on analytic methodologies versus technologies. It empowers a new class of users to easily experiment with data and perform beginning analytic techniques. The beauty of point-and-click tools is that access to analytics is no longer in the hands of just an elite class of programmers or statisticians.
This is not to say that organizations should not put controls on analytic processes – just because you can press a button that says “Build a Model” doesn’t mean that you should – but if you’re trying to broaden and grow the analytic competency of your organization, you need to make the process of learning simpler.
As someone who's implemented analytic applications in a number of organizations, largely to this new class of business analysts, it's tough enough to move them out of their spreadsheet comfort zones. People need incentive to change. Asking them to code would be heresy, met with stubborn resistance and your user adoption will be terrible! So what's the right approach?
First, know your users – classify, profile and target them. Make sure that you align your analytic implementation approach with the way they like to work. Make their lives easier, not harder. There will always be a group that likes to code, and that's perfectly fine, but for your new users, point-and-click analytic tools are a good place to start.
2 Comments
A VP in charge of analytics at a major US bank once told me that his group of analysts program because "code is self-documenting." When he asks an analyst how a result is computed, the analyst shows him the program, which makes it explicit what statistical method is being used. In contrast, a point-and-click interface is less satisfactory (to the VP) because the underlying statistical methods are not explicitly apparent.
I completely understand the argument, but the quote you referenced made me chuckle. Brilliant statisticians are often not brilliant documenters of their process or efficient programmers. My point for people like the one you and I mention in our postings, is that there's room for multiple methods.