Over the past 5-10 years, nearly every organization – private or public, small or large, commercial or non-profit – has developed their own little systems. Some are quite simple and are nothing more than an Excel spreadsheet with a few embedded financial calculations. Some are quite advanced and consist of ERP-like full blown desktop applications which can handle a multitude of different aspects, users, and reporting procedures. Regardless of the underlying technologies, some are quite good and others are simply bad, but we – as software and systems developers – have to acknowledge the three underlying aspects of these systems:
a) they encapsulate the business rules of real users,
b) the tools are already familiar to the users, and
c) the users are already invested in the system
Whenever you are working with or deploying a new system which could replace any functionality of the previous system, you must consider these aspects. Failure to do so will damage your efforts… no matter how “bad” the old system is.
First, previous systems encapsulate the business rules of real users. This is a huge aspect that the requirements will almost never capture. Simply asking “how does your current system work?” will not get to the underlying rules. This is where you need to drag specific scenarios out of the users, determine what is meaningful data, and determine what the existing system would do with those inputs. If the user says, “when I put 1000 in this field, it should show 10000 in this other field”, don't just make it do that! Figure out why the system does what it does.
At this point, the rules of “Add 9000 to field X to get field Y” and “Multiply X by 10 to get Y” are both equally valid. We need more example data to determine the actual rule. If we commit to either one at this point, we're going to look foolish when the customer says “The system should give me 81 when I put in 90! The old system never made mistakes like this!” [As an aside, this makes the actual rule (X/10)^2. While this is a contrived example, you probably see my point.]
If you're thinking “Wow, then I could write Unit Tests!”, then you're on the right course.
Next, users know how to use the existing system. The users know what particular set of key commands they need to perform to take them from one screen to the next or from the general forms to the own. I was once working on replacing a DOS-based application that moved so slowly that a proficient user would key in a set of commands to get to their screens and wait for the system to respond. The point is that they knew the system so well that much of the UI became obsolete and was never even seen. Making something pretty is nice, but misses the point that anything that doesn't speed along user in what they're trying to accomplish is wasted. AJAX is one of the latest examples of this. People want to use it for everything, but as I've noted before, if it doesn't assist the user, don't do it. Gmail is a system which breaks down many of the old patterns, but it does so in a way which serves to assist the user.
Avoid breaking old patterns if you can, but if you must, make the new pattern better, faster, smoother by the users' standards, not your own.
Finally, the users are already invested in the system. Whether you like it or not, the users have used the system for N years before your new one. This is why we call them “users”. This means that unless the system looks and acts just like the old one you will face resistance because they've already been trained and users don't like to change. How do you combat something like this? Get the users involved early in the process and get them invested. When they give you feedback on screens, on functionality, on colors, consider taking it. It doesn't take much to either make the change or determine why it can't be integrated. Even if it's not possible, being able to say “I'd love to do that, but Department X needs that functionality for their workflow.” This opens the discussion for comparisons of workflows because maybe things are quite as similar as you believed.
In addition, each group of users can have their requirements and concerns addressed much earlier in the process. Just because the requirements say one thing, doesn't mean they reflect reality. An actual user may be doing things in a faster more efficient way that makes sense to them OR in a way that is slower but yeilds better results in their situation.
These three aspects of stovepipe systems must be considered. The next time you're working to replace one of these systems, take these aspects into account early in the process. Successfully covering all three will allow the new system to have support from the users because it will take into account their requirements, their usage patterns, and ease the psychological transition.