Easy Peasy apps built by your staff, not programmers
I just saw a blog post today talking about how great it was to have a program, their program of course, that allowed your staff to build programs without calling in I.T. In many ways this is a great idea, I.T. might take too long to get things done, they might over complicate it, or you might not have the idea completely fleshed out till you build some stuff and see what works. Having the people that do the work create a program to help them has a lot of advantages if you have a tool that doesn’t bog them down. But there are some things to be warned about as well. If these apps are ways of looking up company data when and how the staff needs it, terrific, that is a great use of workflow tools. If the staff also needs to record information about actions the are performing in the workflow or about people, places, things or events, this is where it gets a little more interesting.
If the programs information will never be valuable except to the department performing the workflow then all is well, maybe. A department checklist of work done such as a work queue might be an example. But all too often the small helper application becomes a mission critical piece of the business and grows to have data that is very valuable to other departments. Even worse sometimes the app winds up collecting data that other departments are also collecting. Suddenly you find you have two addresses for the same person, one in each department. Or you have records in two programs that show the state of a process differently. How about sales records that don’t match? You have silo’s of data rather than information that is helpful. Now you are faced with a rewrite of these little helper apps to bring them into the core business application or to create a core business application to begin with. Once the application is rewritten the work on the original is lost. Management may not be very happy with having to spend new money to redo things that they thought were already done.
If this happens to you consider this. When the helper program first started you probably had no idea how much it could help. It probably started as a little project with only a few fields that a single person used. Then another person saw it and liked it and started using it. They added ideas, then another and another and so on till it became a very valuable business application. You’ve done a proof of concept, a prototype, you’ve innovated. Now it’s time to take that prototype and turn it into a robust fully integrated part of the overall business. This is where a programmer/database designer can be extremely valuable, getting the underlying model right so that the new production program is scalable both in features and users.
