Software is some pretty amazing stuff. Its very name tells you that it is flexible, changeable, and that it can be molded into all sorts of shapes and sizes. Everything electronic that exists today -- from computers to iPods, electronic ignition systems to jet airliners -- are told what to do by software. Every electronic device is essentially a blank slate that awaits someone to write software for it to tell it what to do. The iPhone has this really cool interface that has changed how mobile devices are used -- but, the really cool interface is not hardware, it's software. Apple could just as easily have made the iPhone act like any other.
With this flexibility comes a lot of work, though. There is a big difference between real life and the world inside software. If you have a basketball and drop it onto a hard floor in real life, the ball will bounce in a very predictable way. The ball is subject to the laws of physics, and is always subject to the laws of physics, so that you can drop the ball one hundred times, and it will always bounce in the same way. The software world is different. If you create a basketball in the software world, you have to create the entire "universe" in which that ball exists. There are no rules, really, to what that universe can look like. If you want to make it realistic, you make it look like a regular gym. But, since there are no rules, the programmer could make the universe be like Mars. Or even just like Earth, only basketballs bounce three times higher than anything else.
In the real world, when you bounce a ball, the ball will always, always bounce in a predictable manner. The ball will never just show up one hundred feet in the air all of a sudden. It will always just bounce. This is not true in Software. There is nothing that prevents a programmer from having a ball bounce along normally, and then all of a sudden have it appear one hundred feet in the sky.
When the movie Spider Man was created, the makers created a very realistic duplicate of New York for the movie. They photographed blocks and blocks, ensuring that buildings that exist in real life were also in the movie version of New York. There was a problem, however. In order for Peter Parker to actually be able to swing from building to building using his wrist-webbing, they had to push the buildings together so that Peter wouldn't smack into the ground when he swung across the street. It looks real, but it's not. You can do this in software, but not in real life.
The point of all this is that Business Software, especially large ERP systems such as SAP or Oracle E-Business, are considered rigid and very difficult to change. In reality, they are just software. All the rules they follow, the screens they have, the way they move data back and forth, the way the data is reported and stored -- all of it -- is completely a fabrication by the designers and programmers who wrote it. And, this is a problem.
Why? Because when you have a real ball and drop it, it will bounce. Always. In addition, it is really, really easy to pick up a ball and have it bounce. However, it is really, really hard to write a ball that bounces in software. It is so complex that errors ("bugs") are likely to be made by the programmers who write the code, sending the ball one hundred feet in the sky. It is so hard that once you have a ball that bounces in software predictably, you want to leave it alone.
In the business world, it is really easy to describe how an order is taken and fulfilled. The customer orders a red widget. When the time comes to ship it, you find that you only have blue ones left. No problem: the customer rep calls the customer who says blue is fine, just ship it. Easy in real life. But really hard to do in software.
When you have an order processing software package, a huge amount of effort was made by the vendor to handle situations like the above -- situations that are innocent enough to describe, but are really, really hard to program transactionally so that the customer can get their widget and still the inventory is correct, the accounting is correct, and the sales reports are correct. When the package gets it right, you really do not want to mess with it.
This is why packages get the reputation for rigidity. Something as seemingly simple such as "just send out the blue one" throws a monkey wrench into the works. Most packages will have a tried and true solution to that scenario (because you can almost guarantee this was on version 1's bug list). It is now part of the core code, and is installed in hundreds if not thousands of customers. Given the size of the install base, this code is probably working just fine now. That's why you really do not want to mess with it.
So these two tensions exist in business software. Software is extremely flexible. You can do anything with software. The software world is a fabrication by the software designers and engineers, and they can tell the system to do pretty much whatever they (or you) want to. On the flip side, it is also extremely hard. This flexibility will cost you. Instead of just being able to write "ball bounce," the programmer has to write the entire universe in which that ball is to bounce, and that is not easy, nor is it easy to change.
When putting in place a new business software system, therefore, you have a double-edged sword to contend with. On the one hand, you can truly get the package to do what you really need the package to do to support your business. If you have some "special-sauce" process that is a competitive advantage for your business, there is a way to get most packages to support it. On the other hand, there is a huge amount of value to leaving the system alone. It is less expensive to implement, less expensive to upgrade, and less likely to fail. Any proposed change to the baseline package, therefore, should be forced to leap a pretty high bar before moving forward with it. Keeping this in mind when dealing with your business systems will save you money and might even save your sanity!