3 ms·

It seems to me that the whole concept of an off-the-shelf ERP is misguided. These systems have to be heavily customized to fit the needs of the any particular o

by ydlr 2y ago

It seems to me that the whole concept of an off-the-shelf ERP is misguided. These systems have to be heavily customized to fit the needs of the any particular organization. Why not just hire a couple programmers, build what you need from the ground up, using open source components where appropriate? It might take longer than 18 months to finish, but it sounds like that wasn't a realistic estimate for configuring an ERP, either.

friendzis 2y ago
In any ERP deployment there will be at least two major cost sinks that have absolutely nothing to do with software: enumerating actual business processes and training employees. Before you can even think of "hiring a couple programmers, build what you need from the ground up" you need a very detailed and thorough spec of what the business actually does and hopefully transform said spec into something better served by electronic processes. How much resources do you reckon would it entail to arrive at such spec? The thing is, you can't agile this. ERP is notoriously hard to deploy. You have warehousing in ERP, but purchasing in paper? Accounting will love you.
- rawgabbit 2y ago
  I believe this is key. Agile is the exact opposite of what should do when writing software for a mature organization like government.
  - friendzis 2y ago
    There's nothing wrong with applying agile on mature orgs per se. With all due respect, technical software people usually fail miserably at understanding what deploying ERP is. It's by no means software project. The "ERP" could be a huge physical book with all required templates even if very inefficient one, nevertheless deploying such "ERP" would still face *exactly* the same problems. Deploying ERP is first and foremost business transformation. All ERP deployment horror stories that I have some inside info on always revolve around reluctance of business to transform and instead attempting to contort ERP to fit some undefined shape. Deploying ERP painfully highlights all the spots where business processes are undefined, overlapping or flat out useless. Those processes need to be cleaned up, there's no way around that. Every information system follows SiSo/GiGo (Garbage in - Garbage out) principle. Humans can apply common sense heuristics and do reasonable things given garbage data. Information systems cannot. That's the beauty and horror of deploying an ERP. If management is actually willing, it's a perfect opportunity to streamline business processes, but if it is managed as some software deployment over existing business - you get horror stories, reduced efficiency and maintenance hell on top.
    - rbanffy 2y ago
      > If management is actually willing, it's a perfect opportunity to streamline business processes This, a million times. Never try to bend an ERP - they are immense business process templates internally connected in incomprehensible ways. Bend the company instead, drop whatever process cannot be implemented trivially in the system and adopt one that is. Just mapping the parts that need to be transformed is a huge process.
NearAP 2y ago
I don’t agree with this. Yes, there are times when processes/procedures are truly unique to a firm but it usually isn’t and the firm can ‘standardize’ their process so that it fits into the ERP flow. These ERPs are usually shipped to handle common/different scenarios/usecases and clients simply have to configure them accordingly (configuration is totally different from trying to customize)

by ydlr 2y ago

friendzis 2y ago

In any ERP deployment there will be at least two major cost sinks that have absolutely nothing to do with software: enumerating actual business processes and training employees. Before you can even think of "hiring a couple programmers, build what you need from the ground up" you need a very detailed and thorough spec of what the business actually does and hopefully transform said spec into something better served by electronic processes. How much resources do you reckon would it entail to arrive at such spec? The thing is, you can't agile this. ERP is notoriously hard to deploy. You have warehousing in ERP, but purchasing in paper? Accounting will love you.

rawgabbit 2y ago
I believe this is key. Agile is the exact opposite of what should do when writing software for a mature organization like government.
- friendzis 2y ago
  There's nothing wrong with applying agile on mature orgs per se. With all due respect, technical software people usually fail miserably at understanding what deploying ERP is. It's by no means software project. The "ERP" could be a huge physical book with all required templates even if very inefficient one, nevertheless deploying such "ERP" would still face *exactly* the same problems. Deploying ERP is first and foremost business transformation. All ERP deployment horror stories that I have some inside info on always revolve around reluctance of business to transform and instead attempting to contort ERP to fit some undefined shape. Deploying ERP painfully highlights all the spots where business processes are undefined, overlapping or flat out useless. Those processes need to be cleaned up, there's no way around that. Every information system follows SiSo/GiGo (Garbage in - Garbage out) principle. Humans can apply common sense heuristics and do reasonable things given garbage data. Information systems cannot. That's the beauty and horror of deploying an ERP. If management is actually willing, it's a perfect opportunity to streamline business processes, but if it is managed as some software deployment over existing business - you get horror stories, reduced efficiency and maintenance hell on top.
  - rbanffy 2y ago
    > If management is actually willing, it's a perfect opportunity to streamline business processes This, a million times. Never try to bend an ERP - they are immense business process templates internally connected in incomprehensible ways. Bend the company instead, drop whatever process cannot be implemented trivially in the system and adopt one that is. Just mapping the parts that need to be transformed is a huge process.

NearAP 2y ago

I don’t agree with this. Yes, there are times when processes/procedures are truly unique to a firm but it usually isn’t and the firm can ‘standardize’ their process so that it fits into the ERP flow. These ERPs are usually shipped to handle common/different scenarios/usecases and clients simply have to configure them accordingly (configuration is totally different from trying to customize)