You might know that I started my banking career at Alexandria National Bank. It was there that I met the very best operations person I have ever known, Michael Umlauf. He was not a programmer or an “IT” person; he was just a very good manager. The best advice I ever got from him was to “know what your input would be (i.e., form, raw data, etc.) and know what you want out (i.e., reports).” When we merged three bank operations into one to form First American Bank in 1978, that was his mantra, and it resulted in the smoothest conversion of systems I have ever experienced (and I have gone through a lot of bank mergers!).
Right now, as I am working on several operational projects, trying to design systems and procedures, Umlauf’s advice frequently comes to mind. Often I collaborate with folks who have never considered the basic “input/output” issues of effective organization. My opinion is that processes must have rules. Unlike dealing with nature, where the rules are already defined, managers should step through what the rules should be before processes are designed.
Last summer Dick Davies wrote a blog titled Value Centric Work Analysis. It talks about defining the work process and how that makes work more efficient. This is a good time to review this information and apply it to what you are working on.
As part of your thinking about processes and rules, I think you should first consider what your customers think is important about the system you are defining. How easy is it to use, what kind of instruction and feedback do they need to use it effectively, and how much of their time will it take to complete it?
Next, I think you should consider how efficient your requirements would be for your staff to interface with. Is there a lot of additional data entry required? From the questions you are asking, is customer input going to be clear? How much time is going to be required to “manipulate” the data?
Finally, I think you need to evaluate what you are going to do with the data you receive. What is the purpose of the process? What reports are you going to produce and whom are you going to show these reports to?
A final opinion: don’t go out and engage an IT person to design the technical parts of your system until you have stepped through your work process and know exactly what you want.
This doesn’t sound much like gardening, does it?