3 ms·

>Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. T

>Example: if you need to visualise your data from multiple sources company-wide, we'd have Tableau (and training, access, templates, portals etc) for example. That means you do it there as per instruction, and you don't go trying to setup some home-brew graph in excel that you manually regenerate every day and forget to generate when you are on vacation. Then your CFO calls up and says, 'I have a meeting in 30 minutes, can you tell me the total cost of pensions for people who work out of the Singapore office on sales admin' and the BI developer never pulled the measures through for that, because nobody asked for it before... so you export it to Excel, do an xlookup, a sumif and a filter and keep your job...or put a request into IT to have it added, wait 3 weeks, and get fired. In the real world there are measures repeated week after week, and there are many more ad-hoc requests. Your mental model of the information required to run a business is way off.

lolinder 2y ago
Exactly. When a process is important enough and repeated often enough, it will move into a more formal system. But most of the time spent running a business is at the fringes of what has been automated and formalized, and this isn't an accident—the automated processes are there precisely because they reduce or eliminate the human time. That means most of the humans (outside of front-line customer support or similar) tend to be working on stuff that is substantially less well-defined than what OP is imagining. Which again gets to my point about the weird perspective on business that we have as software developers. We're called in exclusively to work on those parts of the business that are deemed sufficiently repetitive to be worth automating. That dramatically skews our perception of what running the business should look like.
- oneplane 2y ago
  That's great, but has little to do with the 'excel is my hammer, therefore everything is an excel-shaped nail' problem. Sure, like I wrote (twice already), you might need to have some malleable rows in front of you on your local workstation for some ephemeral work. But the actual workflow happens in the ERP system. Or the CRM. Or the PIM system. Or in Tableau. Or Databricks. And my beef is with people who think their personal flavour of alternate software should bypass that, even when they have been explicitly told not to. When someone needs to stream the truth (data-wise), that comes out of those systems, not some kludgy sheet on someone's network share. Those are the rules that we set up. I don't understand why this is so difficult for everyone to understand (on HN of all places). These are general staff functions we practically have entire schools for, to make people work this way.
  - mopsi 2y ago
    I love that you mentioned PIM systems. I've worked with product information systems from small 3-man companies all the way to Fortune 500 companies, and without exception, their PIM systems have been total dogshit: slow, extremely unintuitive, limited in functionality and borderline unusable. When I need a list of product names, barcodes, weight and dimensions, nothing beats a simple Excel table that can be quickly transformed into whatever format I need at the moment. With the intensity of a thousand suns, I hate the "workflows" of having to create an account, sign in, browse products, put them into a cart, submit an order, and then wait for an email with a download link to some non-standard XML dump or broken CSV that their multi-million dollar PIM system produces. These systems have wasted entire lifetimes worth of their users' time. When it comes to sharing product information, nothing beats the ease of use and flexibility of a plain Excel table.
    - oneplane 2y ago
      Our live PIM database is over 2TB, we're not going to copy that to excel. On top of that, we're also not going to have everyone do a little bit of PIM here and there, we stream 80 to 90 PIM mutations per second across various systems. You get a PIM frontend with appropriate access and that's it. Technically, the only real PIM work the teams do is corrections, there is practically no manual entry. Luckily for us, we put request-response time in the requirements documents, so our PIM users get sub-50ms responses for everything. As for sharing data, our manufacturers and subcontractors use APIs (with the exception of some wanting JSON uploads via SFTP), most of them stream directly into their PIM or ERP (yes, some don't have dedicated PIM systems and just use their ERP for that). Even if we could have the data flow through individual workstations, we'd still not do that as we don't want to legal and repetitional risk associated with that, especially since it is completely avoidable. As written in a different reply, sometimes people want to do some local fiddling around and they will export some data. But that data is considered expired, and not part of the normal data flow. Which was my point: spreadsheets are never part of the main loop. And anyone who wants to build a system where it is, is not working for us. I do notice a trend here, lots of people having bad systems (slow PIM, outdated ERP, missing CRM), which is probably something that should be fixed, rather than taking the shadow route. Escaping to a spreadsheet is just that: escaping.
oneplane 2y ago
In the real world (which is where my example comes from) the CFO expects it in Tableau, all day, every day and isn't going to waste time on the phone with some random people who were assigned to put it in tableau. Perhaps you don't like this example, but that doesn't make it less real.
- jimnotgym 2y ago
  Ok. My real world counterpoint. I work for a CFO at a multinational. A really big one. I have been the finance lead at a multinational myself, a smaller one. Our business changes so rapidly that we are forever adding business units, acquiring, divesting, resizing. The ERP people are years behind us all of the time. What should we do in the mean time with our new group of companies we just acquired? Wait for the IT people?
  - oneplane 2y ago
    If your ERP can't keep up, then that is an ERP-shaped problem. Escalate with the CFO and CTO since the latter probably signed the responsibility/ownership (albeit probably indirectly) for delivery. In the mean time (since the real world is imperfect) you would of course rather kludge it than do nothing. But you would probably not rebuild the entire ERP in excel, forever, which is what I will fight against. We don't have that problem, our ERP team can keep up. Perhaps that is because our rate of acquiring and divesting is maybe 2 or 3 cases per year. We are only active in a couple of countries per BU in the cases I write about, so that makes it easier as well. On the other hand, if the ERP team isn't capable of producing the rate of change needed to support the business requirements, I really hope that you get that sorted since that is practically the entire reason an ERP team exists. We do deploy changes (technical changes) about 200 times each day, of which the teams dealing directly with business workflows do about 60 (including some stock, pricing and WSSI teams). It's not a lot, but it allows us to have nearly no lag time between business needs and implementation delivery. It did take a while to get to that rate, and a 2-week feature freeze one time to shift all processes to a model that allows for this change rate. But it works well for us. (and reporting, visualisation, ETL, and ML are all done without spreadsheets for about 3 years now) As for why we did that (in case that was a question you'd be asking since it is obviously not a change that costs nothing): we no longer wanted to accept the risk of doing it the old way, we also didn't want to have as much onboarding friction due to having many diverse sub-workflows inside teams, because even if you did learn about what someone DIY'ed in your local team, you will still run into the same problem ad-hoc when dealing with other teams, usually at the worst possible time. Same goes for off-boarding, we don't want to spend months trying to figure out what custom stuff someone put in place, especially since you get non-engineering solutions to engineering problems (the excel shaped one) but also engineering solutions to non-engineering problems (the python notebook one). We want our people to be able to spend as much of their time on the actual work instead of side quests that don't add the value we are looking for. It doesn't mean exploration or experiments are banned, but it does mean we want to facilitate as much as we can so you don't have to do anything extra by default.

lolinder 2y ago

Exactly. When a process is important enough and repeated often enough, it will move into a more formal system. But most of the time spent running a business is at the fringes of what has been automated and formalized, and this isn't an accident—the automated processes are there precisely because they reduce or eliminate the human time. That means most of the humans (outside of front-line customer support or similar) tend to be working on stuff that is substantially less well-defined than what OP is imagining. Which again gets to my point about the weird perspective on business that we have as software developers. We're called in exclusively to work on those parts of the business that are deemed sufficiently repetitive to be worth automating. That dramatically skews our perception of what running the business should look like.

oneplane 2y ago
That's great, but has little to do with the 'excel is my hammer, therefore everything is an excel-shaped nail' problem. Sure, like I wrote (twice already), you might need to have some malleable rows in front of you on your local workstation for some ephemeral work. But the actual workflow happens in the ERP system. Or the CRM. Or the PIM system. Or in Tableau. Or Databricks. And my beef is with people who think their personal flavour of alternate software should bypass that, even when they have been explicitly told not to. When someone needs to stream the truth (data-wise), that comes out of those systems, not some kludgy sheet on someone's network share. Those are the rules that we set up. I don't understand why this is so difficult for everyone to understand (on HN of all places). These are general staff functions we practically have entire schools for, to make people work this way.
- mopsi 2y ago
  I love that you mentioned PIM systems. I've worked with product information systems from small 3-man companies all the way to Fortune 500 companies, and without exception, their PIM systems have been total dogshit: slow, extremely unintuitive, limited in functionality and borderline unusable. When I need a list of product names, barcodes, weight and dimensions, nothing beats a simple Excel table that can be quickly transformed into whatever format I need at the moment. With the intensity of a thousand suns, I hate the "workflows" of having to create an account, sign in, browse products, put them into a cart, submit an order, and then wait for an email with a download link to some non-standard XML dump or broken CSV that their multi-million dollar PIM system produces. These systems have wasted entire lifetimes worth of their users' time. When it comes to sharing product information, nothing beats the ease of use and flexibility of a plain Excel table.
  - oneplane 2y ago
    Our live PIM database is over 2TB, we're not going to copy that to excel. On top of that, we're also not going to have everyone do a little bit of PIM here and there, we stream 80 to 90 PIM mutations per second across various systems. You get a PIM frontend with appropriate access and that's it. Technically, the only real PIM work the teams do is corrections, there is practically no manual entry. Luckily for us, we put request-response time in the requirements documents, so our PIM users get sub-50ms responses for everything. As for sharing data, our manufacturers and subcontractors use APIs (with the exception of some wanting JSON uploads via SFTP), most of them stream directly into their PIM or ERP (yes, some don't have dedicated PIM systems and just use their ERP for that). Even if we could have the data flow through individual workstations, we'd still not do that as we don't want to legal and repetitional risk associated with that, especially since it is completely avoidable. As written in a different reply, sometimes people want to do some local fiddling around and they will export some data. But that data is considered expired, and not part of the normal data flow. Which was my point: spreadsheets are never part of the main loop. And anyone who wants to build a system where it is, is not working for us. I do notice a trend here, lots of people having bad systems (slow PIM, outdated ERP, missing CRM), which is probably something that should be fixed, rather than taking the shadow route. Escaping to a spreadsheet is just that: escaping.

oneplane 2y ago

In the real world (which is where my example comes from) the CFO expects it in Tableau, all day, every day and isn't going to waste time on the phone with some random people who were assigned to put it in tableau. Perhaps you don't like this example, but that doesn't make it less real.

jimnotgym 2y ago
Ok. My real world counterpoint. I work for a CFO at a multinational. A really big one. I have been the finance lead at a multinational myself, a smaller one. Our business changes so rapidly that we are forever adding business units, acquiring, divesting, resizing. The ERP people are years behind us all of the time. What should we do in the mean time with our new group of companies we just acquired? Wait for the IT people?
- oneplane 2y ago
  If your ERP can't keep up, then that is an ERP-shaped problem. Escalate with the CFO and CTO since the latter probably signed the responsibility/ownership (albeit probably indirectly) for delivery. In the mean time (since the real world is imperfect) you would of course rather kludge it than do nothing. But you would probably not rebuild the entire ERP in excel, forever, which is what I will fight against. We don't have that problem, our ERP team can keep up. Perhaps that is because our rate of acquiring and divesting is maybe 2 or 3 cases per year. We are only active in a couple of countries per BU in the cases I write about, so that makes it easier as well. On the other hand, if the ERP team isn't capable of producing the rate of change needed to support the business requirements, I really hope that you get that sorted since that is practically the entire reason an ERP team exists. We do deploy changes (technical changes) about 200 times each day, of which the teams dealing directly with business workflows do about 60 (including some stock, pricing and WSSI teams). It's not a lot, but it allows us to have nearly no lag time between business needs and implementation delivery. It did take a while to get to that rate, and a 2-week feature freeze one time to shift all processes to a model that allows for this change rate. But it works well for us. (and reporting, visualisation, ETL, and ML are all done without spreadsheets for about 3 years now) As for why we did that (in case that was a question you'd be asking since it is obviously not a change that costs nothing): we no longer wanted to accept the risk of doing it the old way, we also didn't want to have as much onboarding friction due to having many diverse sub-workflows inside teams, because even if you did learn about what someone DIY'ed in your local team, you will still run into the same problem ad-hoc when dealing with other teams, usually at the worst possible time. Same goes for off-boarding, we don't want to spend months trying to figure out what custom stuff someone put in place, especially since you get non-engineering solutions to engineering problems (the excel shaped one) but also engineering solutions to non-engineering problems (the python notebook one). We want our people to be able to spend as much of their time on the actual work instead of side quests that don't add the value we are looking for. It doesn't mean exploration or experiments are banned, but it does mean we want to facilitate as much as we can so you don't have to do anything extra by default.