Enterprise software is something around which customers can implement change. The customer decides that a prospective software system embodies efficiency or accuracy in business functions that are important. The customer then builds his new process around the software system and thereafter channels incremental process improvement through feature requests etc. These requests occur with some degree of regularity and customers become upset when these requests are ignored or slow to manifest. They want to improve themselves quickly and have a dependence on humans not under their direct employ or control.
When requests are fed to a software vendor - the software vendor generally has a well-constructed method for (i) gathering all requests from all customers, (ii) rationalizing the priority of those requests, and (iii) determining how to convert those requests into tangible changes for how the software system works. The customer has, in effect, subcontracted out change management.
The processes most likely to convert to software are those to which interested parties agree to its general form and are of high value. In a state of constantly changing tactics and strategies, interested parties may not agree to a general form of process or may believe that the process is necessarily in a constant changing state. In this case, software may not exist as a practicable trellis around which to build methods for gathering, prioritizing, or converting improvements; so what then instrument around which the company, which is in its own right an organic piece of enterprise software, manages change? The system should be at least as good as the one to which they have subcontracted (i.e. enterprise software company), but often it is not - WHY?
It is ironic that processes in a high evolutionary state least suitable for conversion to software have themselves generally kludged means of incremental improvement. High tech must find an answer to this riddle somewhere other than spreadsheets and email.