3 ms·

I doubt I misunderstand it since this is what I get paid for. I'm also not suggesting this is a case of large data, ETL or anything like that. (what I'm writing

I doubt I misunderstand it since this is what I get paid for. I'm also not suggesting this is a case of large data, ETL or anything like that. (what I'm writing about is people using it for that anyway which is what we have other systems for and they should not be doing that) Our finance teams use excel too, but not as the 'do everything' tool that the article and plenty of comments here makes it out to be. They use it as a scratchpad, and it works well. But it doesn't contain ground truth, ever. This one perhaps matches with 99% of the rant I wrote: > Then inventory, maybe the ERP didn't split it in the way your consolidation needs it, so you transform the data in Excel and reconcile it back While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there. In some cases the clunky UI makes it slow to do some transformations, even if just to check something to (as you wrote, verify the software did what it was supposed to do), and then you dump a couple of thousand rows out, do your work, and either are happy with what was verified or load some transformed data back in (this hasn't really been needed as we revised our rules as to data locations a few years ago, not in terms of "do this or you get fired" but in terms of "please make sure that when external systems outside of your team streams data in or out of the ERP, the chance of it not being correct is as low as you can get it"). As I wrote in some other reply (which some people appear to disagree with as if it's something I made up), my issue is with the horror cases of people building their own mini-ERP in a set of excel workbooks, or not using shared systems for data sharing and governance but instead emailing files around. Maybe it's the little learning being a dangerous thing, or feeling confident in a tool also giving people false confidence to perform actions that really should not be done that way.

jimnotgym 2y ago
> While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there I don't have much experience with Dynamics. My experience is mostly Oracle, SAP and Netsuite plus some bespoke. I agree modern systems are very flexible. Everything could fit in there eventually if you are willing to pay, and willing to wait. But reporting can't wait. The company I work for has 1000 factories, many sales offices. They use many different ERPs. I heard our division has 23! We were all acquired at different times, . My unit was acquired by a group that subsequently sold a part of itself. They are constantly trying to standardise on one system, but then acquire something else with more different systems. We get around this by using a consolidation system. Export, transform, load of only top line metrics..All via Excel, which is fully integrated into the consolidation system. The consolidation doesn't preserve line level data, so if someone needs it they have to ask for a spreadsheet. The IT just never catches up with the business. The last mega Corp I worked for was simpler and more standardised, but still used different ERPs in different divisions. We were acquired by a group that was acquired by mega Corp, because they wanted a product a different division made. We were shoehorned in. We were on SAP already, but had to move to theirs...took 18 months to get to us. In the mean time...we used a consolidation system... via Excel
- oneplane 2y ago
  We also consolidated from multiple systems but we never had that many in parallel, we always were finished in time before adding/splitting the next set. The previous setup was all SAP, but that was too slow and we couldn't get the change rate we wanted. That was over 10 years ago, and AX had different issues but at least nothing the end-users have to deal with. Besides AX and 365 we have 3 more, as well as some legacy processes still using MSBI, but all of the data going in and data going out is captured (either in Databricks or in our integration systems) which means that reporting and things like invoicing, banking, purchasing etc doesn't really care much about the underlying ERP. The ERP core team of course does, but the days where most of the work was serving direct business day-to-day needs are long gone, it's mostly edge cases and keeping the ERP in line with business changes. All the metrics are processed in spark and exposed to both Tableau (together with an SQL Warehouse that lets you access all the individual data as well), and Thanos. So if a technical team wants to do some deeper analysis side-by-side with technical data that's possible too (which is great since they tend to be more comfortable with that vs. tableau). It's pretty nice to have financial data, WSSI data, GTM data and service deployment data overlaid so you can see the direct impact of everything on everything. (even if the resolution for some data is not the same - zoom out enough and you get very actionable insights) Perhaps one of the differences is what we are mainly in retail, warehousing and logistics, when we buy a product or services business we tend to ditch everything except the data and the people. Our data engineering team takes care of the capture and transformation and the respective specialised process teams (CRM, ERP, PIM, fulfilment etc) coordinate from the business, legal and operational perspective. There will be a cutoff date and depending on the size we'll either have had a realtime streaming period (CDC style mainly) or do a one-off snapshot of the business and do it in one go. For our business users it means they won't need to go to a secondary system to get the 'other' data; instead, the data comes to them. I'm not sure why this method has not failed yet, I suspect it's because some M&A strategy components outline the cost/benefit clear enough to not have us integrate something that is not integrate-able.
  - jimnotgym 2y ago
    >Perhaps one of the differences is what we are mainly in retail, warehousing and logistics You nailed it. At a previous firm (when I was in charge of ERP as well) we took over these kind of firms and moved them into our ERP either immediately or after a few weeks. Manufacturing is orders of magnitude more complex. BOMS, Routings, all the raw and intermediate level skus, interfacing with the shop floor equipment. The much more complex accounts, many more people to train in more specialisms. MRP is so much more complex, planning is more complex. Then with our 1000s of business units... the Politics is so much more complex too

jimnotgym 2y ago

> While we primarily deal with Dynamics (AX and 365), pretty much everything fits in there I don't have much experience with Dynamics. My experience is mostly Oracle, SAP and Netsuite plus some bespoke. I agree modern systems are very flexible. Everything could fit in there eventually if you are willing to pay, and willing to wait. But reporting can't wait. The company I work for has 1000 factories, many sales offices. They use many different ERPs. I heard our division has 23! We were all acquired at different times, . My unit was acquired by a group that subsequently sold a part of itself. They are constantly trying to standardise on one system, but then acquire something else with more different systems. We get around this by using a consolidation system. Export, transform, load of only top line metrics..All via Excel, which is fully integrated into the consolidation system. The consolidation doesn't preserve line level data, so if someone needs it they have to ask for a spreadsheet. The IT just never catches up with the business. The last mega Corp I worked for was simpler and more standardised, but still used different ERPs in different divisions. We were acquired by a group that was acquired by mega Corp, because they wanted a product a different division made. We were shoehorned in. We were on SAP already, but had to move to theirs...took 18 months to get to us. In the mean time...we used a consolidation system... via Excel

oneplane 2y ago
We also consolidated from multiple systems but we never had that many in parallel, we always were finished in time before adding/splitting the next set. The previous setup was all SAP, but that was too slow and we couldn't get the change rate we wanted. That was over 10 years ago, and AX had different issues but at least nothing the end-users have to deal with. Besides AX and 365 we have 3 more, as well as some legacy processes still using MSBI, but all of the data going in and data going out is captured (either in Databricks or in our integration systems) which means that reporting and things like invoicing, banking, purchasing etc doesn't really care much about the underlying ERP. The ERP core team of course does, but the days where most of the work was serving direct business day-to-day needs are long gone, it's mostly edge cases and keeping the ERP in line with business changes. All the metrics are processed in spark and exposed to both Tableau (together with an SQL Warehouse that lets you access all the individual data as well), and Thanos. So if a technical team wants to do some deeper analysis side-by-side with technical data that's possible too (which is great since they tend to be more comfortable with that vs. tableau). It's pretty nice to have financial data, WSSI data, GTM data and service deployment data overlaid so you can see the direct impact of everything on everything. (even if the resolution for some data is not the same - zoom out enough and you get very actionable insights) Perhaps one of the differences is what we are mainly in retail, warehousing and logistics, when we buy a product or services business we tend to ditch everything except the data and the people. Our data engineering team takes care of the capture and transformation and the respective specialised process teams (CRM, ERP, PIM, fulfilment etc) coordinate from the business, legal and operational perspective. There will be a cutoff date and depending on the size we'll either have had a realtime streaming period (CDC style mainly) or do a one-off snapshot of the business and do it in one go. For our business users it means they won't need to go to a secondary system to get the 'other' data; instead, the data comes to them. I'm not sure why this method has not failed yet, I suspect it's because some M&A strategy components outline the cost/benefit clear enough to not have us integrate something that is not integrate-able.
- jimnotgym 2y ago
  >Perhaps one of the differences is what we are mainly in retail, warehousing and logistics You nailed it. At a previous firm (when I was in charge of ERP as well) we took over these kind of firms and moved them into our ERP either immediately or after a few weeks. Manufacturing is orders of magnitude more complex. BOMS, Routings, all the raw and intermediate level skus, interfacing with the shop floor equipment. The much more complex accounts, many more people to train in more specialisms. MRP is so much more complex, planning is more complex. Then with our 1000s of business units... the Politics is so much more complex too