8 ms·

> CUNY Central was so eager to have a centralized MIS tool to use for its own centralizing, corporatizing agenda, that it totally ignored the implications of th

by tqi 2y ago

> CUNY Central was so eager to have a centralized MIS tool to use for its own centralizing, corporatizing agenda, that it totally ignored the implications of the Oracle "configure-only" limitation: business processes would have to be made to fit Oracle, not vice versa. Capabilities that we now have will vanish. The staff, the faculty, the students would just have to "adjust" (the technical term being "suck it up"). This is an interesting perspective. From what I've seen / heard from others, it's generally better to adapt processes to the off-the-shelf tool than to try and customize or build from scratch to accommodate your bespoke processes (especially in the business operations realms). For one, the organization is likely less unique than you think, and those bespoke processes are as often a function of some early employee's preference as it is a genuinely good reason. For another, customizing software is not just a one time cost, since every subsequent update / upgrade is likely to require additional work (or at least testing). And finally, in most cases the closer you are to a vanilla, standard process, the more likely you are to stay in compliance with local laws and regulations. Though I suppose it's possible that the imbalance is just due to the fact that it is much harder to quantify the costs of using a suboptimal (for you) process than it is to look at the procurement contract for a custom solution.

nfriedly 2y ago
One more reason to adapt your process to the tool is that it can make hiring/training easier.
wvenable 2y ago
I've had the opposite experience. Any attempt to adapt processes to an off-the-shell tool have always been a subpar experience for everyone. I've brought a few of these in house as fully custom software and the end result has been a better user experience and faster changes. If we can buy something that fits the need, we will. But if we can't, we build. And we build a fair bit. I disagree with "the organization is likely less unique than you think". If you're big enough you will have unique requirements that nobody else has. I'm in the middle of that now in a project to install some industry standard software that runs the whole business and we have to customize and add custom integration into it. I wouldn't want to build software this complex in house but if I was given the resources and tasked to do it, I could, and it would be better.
- ethbr1 2y ago
  There are two different scenarios. Scenario 1: You're doing something that every other business is doing. E.g. ERP/accounting, sales, contact center, etc. Scenario 2: You're doing something few other businesses are doing. E.g. your actual customer business, creative, etc. (1) is amenable to making your process fit software, to good results. (2) is usually a train wreck. Unfortunately, figuring out if your thing is scenario 1 or 2 is non-trivial. Canonical example: EMR/EHR systems in healthcare. You think they'd be the same... but actually there are so many integrations with other systems and/or different sorts of specialists, that a real world implementation has substantial functionality gaps (papered over with custom work).
  - wvenable 2y ago
    My impression is that most people don't understand just how awful most commercial business software actually is. One thing our business does that every other business does is vacation and overtime tracking. We have a custom in house application for that and we've yet to find a commercial replacement that is, in anyway, half decent. For most Payroll/HR systems, this is merely an add-on feature and doesn't get much attention. For overtime, integration with our financial system allows overtime to be charged to the correct files and this is something that nobody does (or does well). Probably doing just this little bit makes this project pay for itself.
    - BrandoElFollito 2y ago
      Beside the lack of attention, you also have gargantuan legal requirements you need to integrate. Which change all the time. Sometimes a few per country. This is for everything: pay, vacation, etc. It is really complicated.
      - wvenable 2y ago
        One advantage of building in house is that you're only building for your own company. This is significantly less work than building commercial software for multiple clients (which I have also done). I can't overstate how much less work this is and how much of a better experience it can be for users. As an example, for calculating annual vacation entitlement, we have some pretty complicated rules. But every company in every country has their own set of rules so most HR software doesn't bother calculating it -- you just figure it out manually and input it every year for every employee. But because we just have one "client" our rules are just code that we can change as needed and can arbitrarily use whatever information we have. This saves HR a ton of manual work all the time. But this only works because it only needs to be one set of hard-coded rules.
FartinMowler 2y ago
Exactly this! I recall a large survey of SAP deployment projects in the late 1990s. By far the most successful consultancy, out of Chicago I think it was, had it written in their contracts "you'll change your business processes to match SAP; not SAP to match your existing business processes" (more or less). By turning away clients who could not accept that, they had happy clients, happy employees (little burn out), and no runaway costly never-ending death march projects.
- cbsmith 2y ago
  There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way, and so obviously businesses that fit that profile are most likely to get value from using the tool. However, there's a reason other businesses don't work that way, and often retooling to work the SAP would be a net negative. Sometimes retooling SAP to fit the business is also a net negative, in which case the right choice is just to not use SAP, but I've certainly observed cases where there was a benefit from refactoring the tool to fit the business.
  - NearAP 2y ago
    > There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way ERP products are designed following "standard" or "best" practices/processes. It's common to see companies first contract a consulting company to "re-design" their processes before they then try to implement an ERP system.
    - cbsmith 2y ago
      s/ERP/any other business software product/ ...and yet there are all kinds of segments where customized tooling is more the norm than otherwise. It just depends on whether the deviation from the norm is a competitive disadvantage or a competitive advantage. There are a lot businesses where in at least one case, it is an advantage.
  - jll29 2y ago
smt88 2y ago
> From what I've seen / heard from others, it's generally better to adapt processes to the off-the-shelf tool I have never seen this work even once. I've actually built entire businesses on the concept that people are impossible to change, but software is easy to change.
- mooreds 2y ago
  Did you use much off the shelf software? I mean, I'm guessing you used databases and frameworks, but were the business process and UI components off the shelf or custom? Because it's a tradeoff.
  - smt88 2y ago
    I use as much off-the-shelf as possible. But there is real work involved in adapting software to a company's culture. If you do it right, 99% of the work has already been done for you by an existing SaaS or FOSS project, and "all" you have to do is customize it. And generally this doesn't mean "change the config" but rather assemble different building blocks into the right shape. This can still be a multi-year project, even when you're writing almost no code. It takes a long time to understand an existing company's culture, processes, and needs.
- tqi 2y ago
  Makes sense, this is just my personal experience so it's always interesting to hear what others have seen. I recently learned about Mechanical Orchard[1], which seems to have the same thesis (better to update legacy custom software with a modern custom solution rather than migrate to a modern off-the-shelf solution). [1] https://www.mechanical-orchard.com/ https://www.mechanical-orchard.com/
- NearAP 2y ago
  Not ERPs. Customizing ERPs is where consulting firms make money but the ERP vendors themselves advise against this because it becomes expensive maintaining the customizations as new versions of the software and more features are released.
jkaptur 2y ago
Now you have two problems: rolling out the new system and changing the business process. And you'll solve them simultaneously, and if anything goes wrong, you'll roll both back...
- bluGill 2y ago
  Business processes change all the time. Often you are better off changing - if you are more like everyone else you can hire someone who knows your processes and they are useful without a lot of training. So short term costs, but long term better.
  - jkaptur 2y ago
    "IT will tell you what the new process has to be" is usually a pretty tough sell.
wolfi1 2y ago
best example: the €500m disaster Lidl had with SAP [1] https://www.computerweekly.com/news/252446965/Lidl-dumps-500m-SAP-project https://www.computerweekly.com/news/252446965/Lidl-dumps-500...
Spooky23 2y ago
The problem is, the business process shipping with Oracle may be grossly inefficient. Or worse, the former Siebel module and its integration with a former PeopleSoft module may be replaced by some new thing with yet another business process. In any case, CUNY would likely save $300M hiring clerks armed with excel and paper forms. Seems like a lot of money wasted, mostly to advance a “lowercase p” political dispute to consolidate HR functions with a questionable benefit.
themerone 2y ago
I work on bespoke ERP software, it's not an undertaking to be taken lightly, but you are missing a key point. Every process that doesn't your software doesn't accommodate becomes a manual process. There is an employee in a sibling department, using other software, who's full time job doing the work of one of my applications in excel.
cafard 2y ago
My employer used Peoplesoft, in the days before Oracle bought it. Of course, you can't set up Peoplesoft on your own, you bring in consultants. When I reviewed my notes from all the pitches, I found that they all had said that we should modify our processes to suit Peoplesoft. I guess we did--I was new there. I would also say that painful, unduly costly implementations seem pretty standard for ERP products. I have heard such stories about SAP.
- NearAP 2y ago
  I'm not surprised at that. It ties in to my responses [1] [2] 1. https://news.ycombinator.com/item?id=41584410 https://news.ycombinator.com/item?id=41584410 2. https://news.ycombinator.com/item?id=41584391 https://news.ycombinator.com/item?id=41584391

by tqi 2y ago

nfriedly 2y ago

One more reason to adapt your process to the tool is that it can make hiring/training easier.

wvenable 2y ago

I've had the opposite experience. Any attempt to adapt processes to an off-the-shell tool have always been a subpar experience for everyone. I've brought a few of these in house as fully custom software and the end result has been a better user experience and faster changes. If we can buy something that fits the need, we will. But if we can't, we build. And we build a fair bit. I disagree with "the organization is likely less unique than you think". If you're big enough you will have unique requirements that nobody else has. I'm in the middle of that now in a project to install some industry standard software that runs the whole business and we have to customize and add custom integration into it. I wouldn't want to build software this complex in house but if I was given the resources and tasked to do it, I could, and it would be better.

ethbr1 2y ago
There are two different scenarios. Scenario 1: You're doing something that every other business is doing. E.g. ERP/accounting, sales, contact center, etc. Scenario 2: You're doing something few other businesses are doing. E.g. your actual customer business, creative, etc. (1) is amenable to making your process fit software, to good results. (2) is usually a train wreck. Unfortunately, figuring out if your thing is scenario 1 or 2 is non-trivial. Canonical example: EMR/EHR systems in healthcare. You think they'd be the same... but actually there are so many integrations with other systems and/or different sorts of specialists, that a real world implementation has substantial functionality gaps (papered over with custom work).
- wvenable 2y ago
  My impression is that most people don't understand just how awful most commercial business software actually is. One thing our business does that every other business does is vacation and overtime tracking. We have a custom in house application for that and we've yet to find a commercial replacement that is, in anyway, half decent. For most Payroll/HR systems, this is merely an add-on feature and doesn't get much attention. For overtime, integration with our financial system allows overtime to be charged to the correct files and this is something that nobody does (or does well). Probably doing just this little bit makes this project pay for itself.
  - BrandoElFollito 2y ago
    Beside the lack of attention, you also have gargantuan legal requirements you need to integrate. Which change all the time. Sometimes a few per country. This is for everything: pay, vacation, etc. It is really complicated.
    - wvenable 2y ago
      One advantage of building in house is that you're only building for your own company. This is significantly less work than building commercial software for multiple clients (which I have also done). I can't overstate how much less work this is and how much of a better experience it can be for users. As an example, for calculating annual vacation entitlement, we have some pretty complicated rules. But every company in every country has their own set of rules so most HR software doesn't bother calculating it -- you just figure it out manually and input it every year for every employee. But because we just have one "client" our rules are just code that we can change as needed and can arbitrarily use whatever information we have. This saves HR a ton of manual work all the time. But this only works because it only needs to be one set of hard-coded rules.

FartinMowler 2y ago

Exactly this! I recall a large survey of SAP deployment projects in the late 1990s. By far the most successful consultancy, out of Chicago I think it was, had it written in their contracts "you'll change your business processes to match SAP; not SAP to match your existing business processes" (more or less). By turning away clients who could not accept that, they had happy clients, happy employees (little burn out), and no runaway costly never-ending death march projects.

cbsmith 2y ago
There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way, and so obviously businesses that fit that profile are most likely to get value from using the tool. However, there's a reason other businesses don't work that way, and often retooling to work the SAP would be a net negative. Sometimes retooling SAP to fit the business is also a net negative, in which case the right choice is just to not use SAP, but I've certainly observed cases where there was a benefit from refactoring the tool to fit the business.
- NearAP 2y ago
  > There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way ERP products are designed following "standard" or "best" practices/processes. It's common to see companies first contract a consulting company to "re-design" their processes before they then try to implement an ERP system.
  - cbsmith 2y ago
    s/ERP/any other business software product/ ...and yet there are all kinds of segments where customized tooling is more the norm than otherwise. It just depends on whether the deviation from the norm is a competitive disadvantage or a competitive advantage. There are a lot businesses where in at least one case, it is an advantage.
- jll29 2y ago

smt88 2y ago

> From what I've seen / heard from others, it's generally better to adapt processes to the off-the-shelf tool I have never seen this work even once. I've actually built entire businesses on the concept that people are impossible to change, but software is easy to change.

mooreds 2y ago
Did you use much off the shelf software? I mean, I'm guessing you used databases and frameworks, but were the business process and UI components off the shelf or custom? Because it's a tradeoff.
- smt88 2y ago
  I use as much off-the-shelf as possible. But there is real work involved in adapting software to a company's culture. If you do it right, 99% of the work has already been done for you by an existing SaaS or FOSS project, and "all" you have to do is customize it. And generally this doesn't mean "change the config" but rather assemble different building blocks into the right shape. This can still be a multi-year project, even when you're writing almost no code. It takes a long time to understand an existing company's culture, processes, and needs.
tqi 2y ago
Makes sense, this is just my personal experience so it's always interesting to hear what others have seen. I recently learned about Mechanical Orchard[1], which seems to have the same thesis (better to update legacy custom software with a modern custom solution rather than migrate to a modern off-the-shelf solution). [1] https://www.mechanical-orchard.com/ https://www.mechanical-orchard.com/
NearAP 2y ago
Not ERPs. Customizing ERPs is where consulting firms make money but the ERP vendors themselves advise against this because it becomes expensive maintaining the customizations as new versions of the software and more features are released.

jkaptur 2y ago

Now you have two problems: rolling out the new system and changing the business process. And you'll solve them simultaneously, and if anything goes wrong, you'll roll both back...

bluGill 2y ago
Business processes change all the time. Often you are better off changing - if you are more like everyone else you can hire someone who knows your processes and they are useful without a lot of training. So short term costs, but long term better.
- jkaptur 2y ago
  "IT will tell you what the new process has to be" is usually a pretty tough sell.

wolfi1 2y ago

best example: the €500m disaster Lidl had with SAP [1] https://www.computerweekly.com/news/252446965/Lidl-dumps-500m-SAP-project https://www.computerweekly.com/news/252446965/Lidl-dumps-500...

Spooky23 2y ago

The problem is, the business process shipping with Oracle may be grossly inefficient. Or worse, the former Siebel module and its integration with a former PeopleSoft module may be replaced by some new thing with yet another business process. In any case, CUNY would likely save $300M hiring clerks armed with excel and paper forms. Seems like a lot of money wasted, mostly to advance a “lowercase p” political dispute to consolidate HR functions with a questionable benefit.

themerone 2y ago

I work on bespoke ERP software, it's not an undertaking to be taken lightly, but you are missing a key point. Every process that doesn't your software doesn't accommodate becomes a manual process. There is an employee in a sibling department, using other software, who's full time job doing the work of one of my applications in excel.

cafard 2y ago

My employer used Peoplesoft, in the days before Oracle bought it. Of course, you can't set up Peoplesoft on your own, you bring in consultants. When I reviewed my notes from all the pitches, I found that they all had said that we should modify our processes to suit Peoplesoft. I guess we did--I was new there. I would also say that painful, unduly costly implementations seem pretty standard for ERP products. I have heard such stories about SAP.

NearAP 2y ago
I'm not surprised at that. It ties in to my responses [1] [2] 1. https://news.ycombinator.com/item?id=41584410 https://news.ycombinator.com/item?id=41584410 2. https://news.ycombinator.com/item?id=41584391 https://news.ycombinator.com/item?id=41584391