3 ms·
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
by 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.
- eviks 2y ago> Our live PIM database is over 2TB, we're not going to copy that to excel. And you wouldn't need to, you would extract a much smaller subset to Excel and enjoy a superior user interface further analysing that
- oneplane 2y agoOur PIM team disagrees with that take. They enjoy the PIM interface and Excel doesn't come close to the data hierarchy and relationships our systems provide. And that includes reporting, vendor exchange and internal integrations. But perhaps you're missing the point here (like plenty of others): it is not about handling a few offline rows, it's about re-inventing established systems that have proven their value and risk mitigations. We don't want someone to setup a collection files to build a homebrew PIM or ERP or CRM because they feel like it, disconnecting themselves from the organisation and teams they work with. In most cases, single player data silos are bad.
- eviks 2y agoSure, agreeing would be a fireable offence "And anyone who wants to build a system where it is, is not working for us." But the non-PIM teams agree, and they are a few orders of magnitude bigger and more important.
- oneplane 2y agoNo, they don't. Our finance teams, accounting, B&S, purchasing etc. also all disagree with your take. There also is no "fireable offence" structure here, we aren't a US-company and we have strong labour protections here. They themselves chose how they want their processes to work, and none of them ended up with Excel in the main process loop, anywhere. Perhaps this is something you cannot imagine, but over here, this has been the standard for years. And it pays dividends. This does not mean excel doesn't exist or isn't used outside of the main processes/loops/flows. But that is what I wrote in my first comment here, which people seem to skip over.