4 ms·

I agree with the article in broad strokes, but I think it focuses a bit too much on the data science portion. I work for a BI consultancy. There are so many ent

by greggyb 11y ago

I agree with the article in broad strokes, but I think it focuses a bit too much on the data science portion. I work for a BI consultancy. There are so many enterprises where the measure of success in data analysis projects is being able to perform arithmetic accurately and in a timely manner. Data science is a pipe dream for many companies currently. Having up-to-date sales figures that can be sliced by dimensions as simple as product hierarchy, customer, and region is a realistic goal for many of our clients. I am not trying to discount data science. We have a data science practice that does some cool things, but it's so much smaller than the BI practice, because there's currently so much more opportunity for doing basic ETL correctly and simple reporting and dashboarding. There are multiple clients who were looking for "real-time access to data", which was actually synonymous with "automatic weekly refresh would make our lives so much easier. Right now we have to wait on $overworked_analyst to get this out monthly, and depending on workload that can lag by a week or two after the end of the month." These are not exact quotes, but entirely accurate paraphrases. This is the reality for so many organizations that I think sometimes falls out of context in an HN-like environment.

code4tee 11y ago
That's fair. I would agree the bar on data analytics is quite low in many companies. However I've also seen such companies fall exactly into the trap highlighted by the article by thinking some new system will fix all that.
- greggyb 11y ago
  Oh definitely! Like I said, I do agree with the article and just wanted to provide some refocusing and perspective. Tools can help. People are essential, whether it be getting consultants, hiring in-house, or training to acquire expertise.
flashman 11y ago
Our typical client is a retail franchise which has grown its locations on the back of the point-of-sale and recordkeeping system it was using in its first two or three stores. That system hasn't scaled, they're not big enough for the vendor to add features for them, and changing systems would be a massive investment, so they bring us in to write reporting middleware. Sales by category by location by day. Not a lot of science to it for the most part.
- greggyb 11y ago
  Exactly. Or the customer that grows from $10M -> $100M, still running with the same accounting team, who now take >25 days to close the books every month. This is an unfortunately common refrain. I often joke that my job is simply the application of arithmetic under a handful of logical rules, for varying values of "logical". Edit: I don't type so well.
  - Spooky23 11y ago
    I worked for a retailer in college like this... Multi billion dollar company working on some dinky system like you describe. They tied the sales/finance systems to their manufacturing division via some ad hoc lotus notes apps!
    - greggyb 11y ago
      We've been in talks recently with a very large manufacturing customer that is still in the process of coming off Lotus Notes for Office 365. They started last year.
bigger_cheese 11y ago
I come from the opposite side of things to you. I'll provide my perspective. I work for a large industrial plant. My background is in Materials Engineering and Metallurgy. My current job title is "Data Management Engineer" which is pretty unhelpful. If you are familiar with CIM levels in manufacturing I work across level 2-4 (from PLCs's and process automation right up to enterprise historians and Databases) mostly I focus on higher level operational databases and data organization but I occasionally do process modelling and other automation work. I'm not sure how my company compares to the typical retail customers BI companies like to target but hopefully this is useful. Rather than real time access I think Automation would be be the most desirable outcome. The Overworked Analyst you refer to above is definitely something I relate to in our company. If we can free up analysts time from all the mundane data extraction tasks they can add value by actually 'analysing' - not 'extracting'. The same applies whether this is financial data (accountants) or production data(engineers) being analysed. The problem is an industrial plant is not a clean homogeneous operation like a retail store. Equipment breaks down, new equipment gets installed parts of the production line can be decommissioned routed around etc. Our business rules are dynamic constantly changing. A lot of the off the shelf products BI guys pitch to us almost inevitably be out of date the moment it was commissioned. I've not really seen any solution that wouldn't require constant tinkering to keep it up to date and often that requires domain knowledge. Engineers often don't have the software skills and software people don't have the scientific/engineering background. We've had some absolute horror stories with out-sourcing work to contractors without domain knowledge. Even simple stuff can cause complications. One amusing example I can think of is getting back a program full of bugs because the contractor confused the name of a database field "Fe2O3" (Iron Oxide, Fe two 'oh' three) with Fe203 (Fe - Two hundred and Three).
- greggyb 11y ago
  > ... clean homogeneous operation like a retail store ... If you'll forgive me starting with a quote-snip, I think you very much underestimate the complexities of a retail operation. Let me just say that we've had multiple day discussions just about dates with one of our retail clients, specifically how they should be compared year-over-year. In manufacturing, I'm sure you can also understand some of the challenges that exist around inventory. Moving beyond that to the meat of your post, I am familiar with manufacturing. That's one of the major verticals we cover (several of our biggest clients are names you would recognize), and I came up as an analyst in a manufacturing organization. We are a true consultancy. We don't sell products. We're a Microsoft partner, so by the time we're involved the product decision is pretty much made. Our tools are SQL Server, SSAS, and a collection of tools in the presentation layer. None of these are off-the-shelf BI products, but tools to build a BI infrastructure. Our selling point is being able to transform the knowledge and subject matter expertise of people like you into robust models that are suitable for data exploration, ad-hoc reporting, and structured reporting. Our work is bespoke, if you will. You're definitely right that BI is a moving target. If anyone tries to sell you on a build it and leave it solution, they're full of it. Like you said business rules change. A lot of the time (in a well-designed BI solution), these can be captured as data and incorporated into the architecture seamlessly. Sometimes business rule changes do require re-architecting portions of the solution. One of our more recent projects where I was tangentially involved was implementing work-in-progress reporting for one of our manufacturing clients. I can tell you that the equipment turnover and production line rerouting problems are all well-covered. They can spin up and down production lines, factories, reroute product between steps and that's all covered in the existing architecture. Even in less dynamic environments, it's hard to call a BI solution done. If the processes and data don't change, that's just an opportunity for the sophistication of the questions and analysis to progress. I don't say this from a position of greed and job security (though the security is nice, for sure (: ), but from one of honest observation. Once you know what has happened and is happening, you start asking why and what will happen, and once you can answer those, you ask how to change what will happen. This latter portion is where the data science of the parent article comes in.
IanCal 11y ago
A couple of partially relevant things: Something that drives me to really ask what the requirements are is building something for my Dad. It was a tool to do deconvolution of MS spectra, and he said it needed to run "quickly". I got versions down to an hour, then 15 minutes and bottomed out at about 5 minutes for a decent result. After a while I talked to him about the timings and he said that "quickly" meant "under a day". A failure on my part to clarify what is a really fuzzy term. Linked to that, at the time they had a process which involved someone frequently manually looking up an item in a ~3-5k list. I'm a data scientist, and I think that the amazing tools available now can really cloud the problems that are faced by many organisations. Sure, we can use word-sense vectors to create a deep neural net to do a thing, but 4% of your data has a country of "NONE". Or you've got dates that don't make sense (1000 years into the future), or a suspicious amount at 1/1/1970, 1/1/1900 and 1/1/1904. I've seen important things with "ZZ TEST DO NOT USE" as a field, there's truncated data, broken encodings and more. This isn't to make fun of the people with these errors, getting and keeping good data is hard and often overlooked. But unless you've got that, you're probably not going to be able to get anything useful from the fancy algorithms. And even then, there's a huge amount to be gained from improving simple interactions at the point humans and computers interface.
- PaulHoule 11y ago
  Oddly these issues are predictable and I think there is a lot of potentials for tools to solve these exact problems. I am skeptical about the possibility of throwing bodies at the problem because what you find is that everybody is excited about getting things done yesterday and not about getting things done correctly, consistently, or repeatably and without that mo' people, mo' data and mo' money just means mo' problems.
- greggyb 11y ago
  I can't express surprise at any of this. A few responses: I hope that list was sorted. 4% of Country = "NONE" sounds like they're running a tight ship compared to some places I've seen. At least those date fields don't have "Unknown" as a value. Yes, I have seen the date field stored as text. You are absolutely right. The ETL side, nailing down appropriate business logic, chasing down source errors and inconsistencies, altering processes to capture the data we need to give good answers; these are the challenges that take >80% of our time. If we do our job right in these pieces, the reporting can be done by an intern who learned how to use a pivot table yesterday.
Outdoorsman 11y ago
From my experience you are correct... Most of my clients are "afloat" because they have a viable product..."big data" is something far down the road to them...

by greggyb 11y ago

code4tee 11y ago

That's fair. I would agree the bar on data analytics is quite low in many companies. However I've also seen such companies fall exactly into the trap highlighted by the article by thinking some new system will fix all that.

greggyb 11y ago
Oh definitely! Like I said, I do agree with the article and just wanted to provide some refocusing and perspective. Tools can help. People are essential, whether it be getting consultants, hiring in-house, or training to acquire expertise.

flashman 11y ago

Our typical client is a retail franchise which has grown its locations on the back of the point-of-sale and recordkeeping system it was using in its first two or three stores. That system hasn't scaled, they're not big enough for the vendor to add features for them, and changing systems would be a massive investment, so they bring us in to write reporting middleware. Sales by category by location by day. Not a lot of science to it for the most part.

greggyb 11y ago
Exactly. Or the customer that grows from $10M -> $100M, still running with the same accounting team, who now take >25 days to close the books every month. This is an unfortunately common refrain. I often joke that my job is simply the application of arithmetic under a handful of logical rules, for varying values of "logical". Edit: I don't type so well.
- Spooky23 11y ago
  I worked for a retailer in college like this... Multi billion dollar company working on some dinky system like you describe. They tied the sales/finance systems to their manufacturing division via some ad hoc lotus notes apps!
  - greggyb 11y ago
    We've been in talks recently with a very large manufacturing customer that is still in the process of coming off Lotus Notes for Office 365. They started last year.

bigger_cheese 11y ago

I come from the opposite side of things to you. I'll provide my perspective. I work for a large industrial plant. My background is in Materials Engineering and Metallurgy. My current job title is "Data Management Engineer" which is pretty unhelpful. If you are familiar with CIM levels in manufacturing I work across level 2-4 (from PLCs's and process automation right up to enterprise historians and Databases) mostly I focus on higher level operational databases and data organization but I occasionally do process modelling and other automation work. I'm not sure how my company compares to the typical retail customers BI companies like to target but hopefully this is useful. Rather than real time access I think Automation would be be the most desirable outcome. The Overworked Analyst you refer to above is definitely something I relate to in our company. If we can free up analysts time from all the mundane data extraction tasks they can add value by actually 'analysing' - not 'extracting'. The same applies whether this is financial data (accountants) or production data(engineers) being analysed. The problem is an industrial plant is not a clean homogeneous operation like a retail store. Equipment breaks down, new equipment gets installed parts of the production line can be decommissioned routed around etc. Our business rules are dynamic constantly changing. A lot of the off the shelf products BI guys pitch to us almost inevitably be out of date the moment it was commissioned. I've not really seen any solution that wouldn't require constant tinkering to keep it up to date and often that requires domain knowledge. Engineers often don't have the software skills and software people don't have the scientific/engineering background. We've had some absolute horror stories with out-sourcing work to contractors without domain knowledge. Even simple stuff can cause complications. One amusing example I can think of is getting back a program full of bugs because the contractor confused the name of a database field "Fe2O3" (Iron Oxide, Fe two 'oh' three) with Fe203 (Fe - Two hundred and Three).

greggyb 11y ago
> ... clean homogeneous operation like a retail store ... If you'll forgive me starting with a quote-snip, I think you very much underestimate the complexities of a retail operation. Let me just say that we've had multiple day discussions just about dates with one of our retail clients, specifically how they should be compared year-over-year. In manufacturing, I'm sure you can also understand some of the challenges that exist around inventory. Moving beyond that to the meat of your post, I am familiar with manufacturing. That's one of the major verticals we cover (several of our biggest clients are names you would recognize), and I came up as an analyst in a manufacturing organization. We are a true consultancy. We don't sell products. We're a Microsoft partner, so by the time we're involved the product decision is pretty much made. Our tools are SQL Server, SSAS, and a collection of tools in the presentation layer. None of these are off-the-shelf BI products, but tools to build a BI infrastructure. Our selling point is being able to transform the knowledge and subject matter expertise of people like you into robust models that are suitable for data exploration, ad-hoc reporting, and structured reporting. Our work is bespoke, if you will. You're definitely right that BI is a moving target. If anyone tries to sell you on a build it and leave it solution, they're full of it. Like you said business rules change. A lot of the time (in a well-designed BI solution), these can be captured as data and incorporated into the architecture seamlessly. Sometimes business rule changes do require re-architecting portions of the solution. One of our more recent projects where I was tangentially involved was implementing work-in-progress reporting for one of our manufacturing clients. I can tell you that the equipment turnover and production line rerouting problems are all well-covered. They can spin up and down production lines, factories, reroute product between steps and that's all covered in the existing architecture. Even in less dynamic environments, it's hard to call a BI solution done. If the processes and data don't change, that's just an opportunity for the sophistication of the questions and analysis to progress. I don't say this from a position of greed and job security (though the security is nice, for sure (: ), but from one of honest observation. Once you know what has happened and is happening, you start asking why and what will happen, and once you can answer those, you ask how to change what will happen. This latter portion is where the data science of the parent article comes in.

IanCal 11y ago

A couple of partially relevant things: Something that drives me to really ask what the requirements are is building something for my Dad. It was a tool to do deconvolution of MS spectra, and he said it needed to run "quickly". I got versions down to an hour, then 15 minutes and bottomed out at about 5 minutes for a decent result. After a while I talked to him about the timings and he said that "quickly" meant "under a day". A failure on my part to clarify what is a really fuzzy term. Linked to that, at the time they had a process which involved someone frequently manually looking up an item in a ~3-5k list. I'm a data scientist, and I think that the amazing tools available now can really cloud the problems that are faced by many organisations. Sure, we can use word-sense vectors to create a deep neural net to do a thing, but 4% of your data has a country of "NONE". Or you've got dates that don't make sense (1000 years into the future), or a suspicious amount at 1/1/1970, 1/1/1900 and 1/1/1904. I've seen important things with "ZZ TEST DO NOT USE" as a field, there's truncated data, broken encodings and more. This isn't to make fun of the people with these errors, getting and keeping good data is hard and often overlooked. But unless you've got that, you're probably not going to be able to get anything useful from the fancy algorithms. And even then, there's a huge amount to be gained from improving simple interactions at the point humans and computers interface.

PaulHoule 11y ago
Oddly these issues are predictable and I think there is a lot of potentials for tools to solve these exact problems. I am skeptical about the possibility of throwing bodies at the problem because what you find is that everybody is excited about getting things done yesterday and not about getting things done correctly, consistently, or repeatably and without that mo' people, mo' data and mo' money just means mo' problems.
greggyb 11y ago
I can't express surprise at any of this. A few responses: I hope that list was sorted. 4% of Country = "NONE" sounds like they're running a tight ship compared to some places I've seen. At least those date fields don't have "Unknown" as a value. Yes, I have seen the date field stored as text. You are absolutely right. The ETL side, nailing down appropriate business logic, chasing down source errors and inconsistencies, altering processes to capture the data we need to give good answers; these are the challenges that take >80% of our time. If we do our job right in these pieces, the reporting can be done by an intern who learned how to use a pivot table yesterday.

Outdoorsman 11y ago

From my experience you are correct... Most of my clients are "afloat" because they have a viable product..."big data" is something far down the road to them...