Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I would say yes and no.

It's true that enterprises have complex and unique workflows, and that this drives the complexity of enterprise software. What I doubt is that this complexity is actually adding value in most cases.

There is a nice equilibrium where companies adopt simple best practice workflows for non-core competencies, and vendors compete on how effectively they can implement those simple workflows.

In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility.



Thing is, enterprises have multiple incompatible workflows but still need to make it work. I.e. due to mergers and acquisitions different parts of the company have 3 different, incompatible IT workflows for part procurement.

Of course that's bad and a single system is highly desired - so the company is working on it, and within a year these three workflows are going to be combined in a single system. Naturally, that system isn't simple as it needs to combine the peculiarities of these three workflows.

Of course that's bad, and a single simpler workflow is highly desired - so the company is working on it, and within 2-3 years the processes are going to be adjusted and unified so that there's a reasonable single process.

However, there's another acquisition that's going to be finalized soon, and during these 2-3 years at least one more is going to happen, so by the time these workflows are unified and simplified, they will be joined by new parts of the company using different workflows, and the enterprise will be back to square one with 3 separate systems with incompatible workflows for doing the same thing.


Oh, I'm aware. I work in enterprise software. I see what the customers want.

I've also been on the receiving end: my company has one tool that doesn't work well. So for three years, there's been a push to get rid of it, but there's never been agreement on any replacement.

There's one particular use case that stakeholders think isn't handled by the replacements. The result is that we use both tools, and manually synchronize them. Someone wrote a bespoke automated tool to bridge those two SaaS apps, but it doesn't remove the manual synchronization, just reduces it.

Oh, these tools? They aren't for something low touch. People are in both tools constantly. There are questions about which pieces of information are accurate, and who's responsible for which updates. The time waste is significant.

But the problem isn't the software. The problem is that people can't make a decision. When you ask someone higher up, you get vague assurances that we're still thinking about the issue. In the case of the companies with their mergers, having one tool support both systems isn't doing anyone any favors. It just lets them limp along with excess complexity.


> In reality, we're stuck in the equilibrium where companies cling to baroque workflows for everything, and vendors compete to support those workflows, sacrificing ease of use, implementation time, and agility.

Enterprises are setup to support all of these baroque workflows and that's where most of the value is derived. However users and the business don't get that value, and the project to replace the previous one will deliver "value" to IT stakeholders. The cycle repeats.

You have enterprise architects who in the worst case are creating uncertainty by supporting different factions and introducing new tools which interest them versus meeting goals for the company. IT outsourcing vendors are responsible for the implementation and frequently do a less than stellar job. Security are split between trying to keep tabs on how the outsourcer is running things, while trying to limit how much damage business areas do by just delivering their own solution with SaaS or a small vendor. This is a real mess that requires huge amounts of energy, and is hard to fix because everyone is doing pretty well from it in their own way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: