Having spent a significant period of my life both designing and writing networked information systems, one thing has stuck out to me: there is not actually that much code. There is plenty of data, but the actual amount of computation is both scant and technically not very challenging. Translation: there is not a lot of code to write and the code that there is to write is easy, easy stuff.
What is a challenge is getting that code to put the correct information in front of the correct people so that they can inform themselves and make wise decisions or otherwise enrich their experiences, with as little cognitive overhead as can be managed.
The products on the market, be they open-source or effectively take a share of your revenue, operate as if they are a drop-in solution for a particular problem, as if it was generic and well-defined, like swapping a BIC pen for a Pilot pen. But we know that the more expansive a software package gets, the more onerous it is to operate, and the more it costs to customize. I further submit that networked information systems like ERP/CRM/CMS/LOL/WTF often risk costing more to integrate than writing a system from scratch, with the investment asymptotically approaching infinity as the product approaches effective. I have witnessed this personally.
I therefore propose an alternative way to think about software: It is an executable instance of its author's opinion, to an extreme degree of specificity, of how a certain business process ought to happen. This does not predicate that such an opinion is well-informed. The hazard here is that a software product, trivial or grandiose, is far from confined from affecting business processes other than the one it was intended to facilitate.
Consider the aforementioned example of a writing instrument: no matter what an industrial designer does with a pen, it will scarcely affect your ability to write. Likewise a typewriter, to a slightly lesser extent. A word processor, on the other hand, will not only shape the way documents are created and managed within a business, but the businesses that surround it as well.
The architects of enterprise software inexorably suffer from a dearth of information relative to the complexity and nuance of their charge. The result is to overprescribe some behaviour and completely neglect others, then make up the shortfall with an extension interface.
Again, the data is the most important consideration. This includes capturing the data, storing and concentrating it safely and in its most consistent form, routing it to the right people, keeping it from the wrong people, arranging it to an arbitrary degree of granularity, operating over it and extracting it in a way that is useful to other systems.
The more expansive the product, however, the more arcane is its internal structure, barring an explicit consideration toward integrity and transparency. Likewise, for the reasons I mentioned above, it is entirely probable to commit to a solution that inhibits or outright prohibits certain necessary activity. To perform the necessary due diligence when evaluating a product of this kind is nine-tenths of the work of acquiring a bespoke solution. The question, then, is what are we paying these vendors for?