There is NO internal process that has no answer. Period.
Again, the problem is always that businesses — or developers — get this notion that it doesn’t fit “their” way of working. They fail to consider whether they’re doing it wrong. A business should be willing to change when the process does not match the common — in other words, if you’re working a process like fraud, yet you do it 100% different from every other fraud department, you’re the one doing it wrong!
Case-in-point: I had a customer who bought KnowledgeLake and wanted to integrate it with another ECM system. KnowledgeLake, at the core, is a SharePoint plugin. It depends 100% on Sharepoint to function. It can only access documents stored in SharePoint. SharePoint uses blob storage, not distributed file storage. That means KnowledgeLake would have to write an API to see or store any files from another ECM system. They are competitors.
When explaining this to the customer they said, “well, blob storage is preferred, isn’t it?”
No, it’s not.
“But that other ECM system has a SharePoint plugin, right? So can’t you just dump the file from the ECM system into SharePoint?”
No, you can’t. The SharePoint plugin is one-way. You have to write an API if you must connect the two. What problem are you trying to solve?
“Well, KnowledgeLake has this really cool annotation feature where users can draw on PDFs!”
The ECM has that too.
“Yeah, but it’s not SharePoint based.”
Ok…so…why consider the ECM system then? Why not just keep using KnowledgeLake?
“Well, because KnowledgeLake doesn’t have any sort of document retention or workflow features.”
SharePoint does. Why not just configure them?
“Well, because SharePoint’s a pain to work with, we’d have to hire a SharePoint developer, I mean the ECM system has fantastic document retention and workflow, we want that, we just don’t want to use it’s interface and we don’t want to code something. Can’t the ECM system just rewrite its integration so KnowledgeLake will work?”
No. If KnowledgeLake is deficient, it’s deficient. Your problem isn’t the ECM system, it’s KnowledgeLake. You like one small piece of it and hate the rest, yet refuse to live without that one small feature that adds very little overall value.
That’s only a snippet of that conversation, but you see what I’m getting at. That’s an example of a customer that doesn’t know what they need and they’re biased over a silly, petty feature that every good content solution has. They’re not willing to hear the right answer — in that case, deal with KnowledgeLake and its limitations, or deal with the ECM system and its limitations, or write an API between the two and eat the cost. They turned down all three options. There are no others!
So yes, change is a good thing when it means that you are doing things consistent with everyone else that uses a thing.