Packaged Software vs In House Development
Most associates (employees) in companies are having one duty: to "consume (read) data" and then to "produce (write) data", according to their expertise, and after that "transfer data produced" to others.
...it is as simple as that.
Even employees that their main job is "handling" of "matter" or "people" are "heavy consumers" of data. After consuming the data they "produce" some data (...check some boxes or writing some essays) and then "transfer" the data to others.
The "good quality", "right quantity" and "proper timing" of arrival of data to be "consumed" by good expertises "produces" the "good products" to be delivered to the market.
kosmos Business Operating System (kosmos/BOS) has been made on the purpose to streamline the flow of data from expertise to expertise, collect their produced data and transfer those data to others. kosmos/BOS lets companies create their own "way of working" into an "automated team work". So our tool permits companies to build automation to their organized team, something that is an exclusive expertise known to the company and nowhere else.
On the other hand, packaged software, mainly targets on the "expertise data producing". Because of this feature creates obstacles and "lakes of data" before its usage and after its usage. I mean that data are imported heavily (creating also duplicates) and are exported to the others also heavily needing conversions. The final experience by a big pleathora of "packaged software" used in a company I think supports my argument here.
Naturally the above analysis on packaged software is from the point of view of kosmos/BOS technology. Continuing the above I think that the future in good packaged software is strictly as a tool for "data producing" by expertises (given that data "read-in" is made directly from the "one big company's" database and the "write-out" to the same database in order not to form "data lakes" before of after the package usage).
As a conclusion, I believe that business processes heavily concerns on "data transfer" and "coordination of work" (something that is every company's exclusive technology on the field) and not "data producing" (because the final data outcome is in most cases some lines of "guidance" or "numbers" to be "directed" (or flow) to the proper associates).
I believe that an experienced IT expertise can see reason on the above.