@Chris Would you agree that there is a need to build the infrastructure of analytics at the same time as deviring the analytics strategy that somewhat drives analytics at the same time? I guess what I mean is, do you start with one business problem and then begin to build the infrastructure of your analytics data, tools, team etc. . . or should this be both a grass roots approach (i.e. working to clean data, seeking out tools for visualization or analysis) as well as a top down business strategy effort?
Jamescon, true. Functional managers should get involved. I just recently faced this and I got a bad flock. Then I went on to LinkedIn and posted vacancy to the right groups and I got the right man for the job
In the example of the late payments they should have designed the 'intervention' mechanism first and then worked backwards. Or they should have incentivized the customer service reps on reducing accounts receivable.
I like the idea of managers being more involved in the screening, recruiting process. Not only does a lot get lost in translation with the HR team, but that manager can really help to refine the search once resumes start coming in. I've worked with managers who left the whole thing (prior to actual in-person interview) to HR and the result tends to be a bad hire or bad flock of candidates.
I see a question about exploratory analytics. I absolutely think there is a role for this. There are cases where truly 'exploratory' and 'unsupervised' analytics is a appropriate. My hypothesis is that MANY organzations should have 80+% of the effort (initially) on well defined business issues / opportunities.
Chris welcome back. In case you missed it: @chris. One thing we were discussing on the chat board is the aspect of knowing the business problem before you launch an analytics project. However, one poster noted that sometimes it's the analytics project that identifies the problem. Do you see a role for an "exploratory" analytics project on occasion, versus the more typical "operational" (problem driven) project?
@chris. One thing we were discussing on the chat board is the aspect of knowing the business problem before you launch an analytics project. However, one poster noted that sometimes it's the analytics project that identifies the problem. Do you see a role for an "exploratory" analytics project on occasion, versus the more typical "operational" (problem driven) project?
I see many questions about job descriptions...this is tough to answer generally as it really gets to being very clear about the various roles that are needed. I have seen lots of examples of job descriptions that are looking for 'unicorns' as opposed to thinking about building blocks to a team.
How do you get a champion at a high enough level to promote, support, and make progress in developing out the positions and garner resources and cooperation to include analytics in a business strategy?
HR: How many years experience should the applicant have? MANAGER: Ah, well it's not so much about years of experience as it is about the skill sets and the person fitting into the organization's culture. HR: Right, but how many years, if you had to quantify it? MANAGER: Well, they should have *some* experience, probably. But they don't need to be a subject matter expert... HR: So how many years? MANAGER: A few, I guess. HR: So, like, 3? MANAGER: Ah, two to three, sure.
JOB POSTING: MUST HAVE TWO TO THREE YEARS OF EXPERIENCE
Question: How to communicate these needs -- for instance, exceptional visualization skills -- to the HR department and help make sure that these very spatially minded people aren't being weeded out by the word-screener?
@digitalarchitect. No doubt, we can't limit analytics to those problems that we as humans know. My concern is with the analytics project that runs off on its own in a back room somewhere without understanding what people are seeing in the customer-facing or operations roles.
John Barnes, as I recall, has some great pieces in the A2 archives about interpreting the data and analysis to tell a human story. Here's one on correlation vs. causation: http://www.allanalytics.com/author.asp?section_id=1413&doc_id=247352
Agree with @Joseph. To some extent, limiting your starting point to starting with business use cases can limit the usefulness of your data and the story it can tell. You could be assuming that only those business problems we are aware of or have already identified are the only justification for developing analytics from the data you have. I'm convinced that there are plenty of hidden issues or insights that could be illiminated if you are starting from the data looking for indicators that ultimately generate new and maybe even more appropriate business use cases that need to be addressed. It seems like having a business case ahead of time could narrow your scope of insight.
Yes. Tell a story. Define your business problem. Enumerate the business environment factors at play and the raw data. Use case studies related to similar situations and explain how they're the same or different from your own situation. Then apply the data and analysis to your own present business problem.
@Joe. The way I look at it personally is that exploratory analytics spawn a closer look and maybe another round of analytics that ends with "Here's how you can fix the problem that we discovered in the exploratory stage."
Yes, because people respond to stories more than to numbers alone. Someone even pointed to that as the reason people are not as concenred about hacks as they should be -- the threat stays abstract as numbers.
It seems this is a chicken and the egg problem. There are questions that already exist that are business problems that are needed to be solved, but there are also "problems" or insights that can be discovered by actually just looking at the data and trends in the data that you have. It seems to me that there are even business problems that were unknown that can be illuminated by being able to evaluate the data using tools that help to tease out trends, correlations, and patterns that would not been seen without analytics.
Ariella, by contextualizing, do you mean in the collections example? I think the issue there was that you probably had people who had plenty to do as it was, and nobody thought to say, "You can help us collect these debts, and you get a share of it."
Curt's point is so dead-on here. Technology is not the be-all and end-all. It's an important element, but it's all about the deployment, the culture, and other human aspects ultimately. The tech is just a tool.
In monitoring analytic pros' comments on sites and in social media it seems that there is a subset (not a majority) who forget that somewhere down the line there is a human who has to put that data into action in day to day work.
We'd love to have your voice in the discussion here. To take part, just type your comment into the "Your Post" box and then click on the "Post" button below the box. Feel free to introduce yourself before the show starts -- I think you'll find that we're a very friendly community here!
Hey, everyone, we're glad you could join us! When the show is scheduled to start, an audio player should appear above the "Your Post" window. If it doesn't appear, you might need to refresh your browser until it does. If it appears but doesn't start playing, then you may need to click on the "play" button on the far left of the player.
Get up to speed with emerging analytics technologies including Natural Language Processing, Edge Analytics, Machine Learning, Real-time Analytics, and Augmented Analytics. These expert-led sessions are for analytics leaders, professionals and business users.
Get started with tomorrow's analytics technology. Sign up today.