It is essential that the people that work with a solution understand the purpose of that solution. All too often the solution simply becomes company policy or standard operating procedure, with people following it routinely. The original problem might long ago have gone away, or it might have changed in ways that make the original solution no longer useful. But unless people understand the intended purpose of what they are doing, they can easily end up habitually performing tasks that have become inefficient or useless.
Colin Powell tells a story from his Vietnam War experiences. An Army outpost was stationed in a very vulnerable location, but the resulting casualties were deemed necessary in order to provide defence for an essential airfield nearby. The Air Force's planes were continually under attack every time they landed or took off, but the resulting casualties were deemed necessary in order to provide supplies for an essential army base nearby. And of course, no one knows why, other than to defend and supply each other, either the base or the airfield were needed in the first place. It sounds like a sick joke, but is apparently true.
There are stories of corporations where, as the company grew, someone gathering statistics eventually became several people, and eventually involved the operations of multiple departments. People would carefully screen data and gather information, ship it off to others who would organize it, ship off the results to others who would analyze it and prepare reports, which were sent to be filed away in a warehouse. Everyone worked hard at their jobs and understood how important and essential their work was. But because this particular work stream was only part of what each department did, no one could see the big picture of this one set of tasks. The person that had originally requested the statistics had died decades ago, but the project continued to thrive and grow long after anyone had any need for it.
I experienced a similar situation many years ago on my first co-op work term, though it wasn't until after I had left that I realized the truth. In those days, computer data was input from punched cards. The device that read the cards could run at a very high speed when reading batches of cards, but required a relatively long start-up time to read the first card (various mechanical parts had to come up to speed). Any program that processed its input one card at a time could take hours to run if the card reader had to cycle down and up again between each card. So the company developed a procedure that eliminated this delay. Every job would be preceded by another job that simply read all the input cards at once, copying them onto a magnetic tape. The real job would then read the card images from the tape, which had a much smaller latency time.
By the time I started there, the company had upgraded their old computer to IBM's new DOS (Disk Operating System), which used hard-drives to store data. IBM was well aware of card-reader latency problems, so the new operating system automatically copied all jobs and data entered via the card reader to disk before running them. The company however seemed unaware of the significance of this and continued following their standard procedure of inserting their copy-to-tape step at the beginning of each program. So now this standard trick intended to speed things up was now copying the data from fast disk onto slower tape, and the real job was reading card images from the slow tape rather than from the fast disk. If they had simply removed the copy-to-tape step, everything would have run much faster, but that step had become so ingrained that no one understood or even thought about its purpose. They were still doing this with every job they ran when I left after my two work terms there. Maybe they still are.