Blog

Input Management

by | May 16, 2011 | Input Management | 4 comments

Input Management

I shouldn’t knock the term Input Management because it is fitting for what I’ve been involved with, but it is vague. This vagueness, allows competing companies to use any definition to best fit what they are trying to sell. (That is for another blog.)  So, let us focus on your business problem. The bottom line is:

You need to know how to get all of this “stuff” into your system, so you can get value out of it.

The “stuff” can be anything really. You may have documents in need of scanning, faxes in need of capturing, bills in need of paying, email in need of storing, or system reports in need of monitoring.  You may even have B2B files just needing to be loved.

Where do you begin?

I always ask two questions at the beginning of any project. The first question is “What do you want to get out of your system?”

My second question would be (for Input Management specifically), “Are there any other systems with your information already in it?”

These two questions are important to ask, because if you have been involved with software development any period of time you have heard the term GIGO (Garbage In, Garbage Out).   All systems have input and output. We developers/designers are constantly trying to figure out how to keep input valid and relevant, so output is valid and meaningful.  Validity is important to make certain what you are getting is correct.  Relevance is important to make certain what you are getting is meaningful (and in a lot of cases profitable).

Maintaining a clear understanding of what expectations you have of your system allows you to keep focus on what is relevant to put into the system.  (Remember, irrelevant data is expensive data.)

Getting a good understanding of what information you already have helps software designers know how to validate data as it is coming in.  It also helps to eliminate storing redundant data.  (Redundant data is very expensive data.)

Challenge

So my challenge for you, if you are starting an Input Management project, is to go back over your business requirements document. (You do have one, right?) Make certain you have a list of what information is necessary to running your business, and make certain all of your capture requirements match up with your list. If they don’t match anything on your list, consider moving them out of scope for the time being.

Bonus Challenge: Write down what systems you expect to tap to get valid data from, and consider where the data needs to be managed to avoid data redundancy.

Next Time…

Next we will look into how different tools tackle the Input Management need…

Categories

4 Comments

  1. James Bailey

    The first paragraph through me for a loop, but I like your questions. Like many things, we should define the perceive value and end state – even if temporary – for any project. If you do not know where you are going, how will you know when you get there? The same goes for knowing the problem you are solving.

    Reply
  2. Lee Grayson

    Yeah, the first paragraph got away from me. You should have seen the raw version.

    Being asked to blog on this topic reminded me of when Captiva came up with the term “eInput Management”, because there just had to be a designation for electronic vs. physical content. It was as if there was something really different to do after the physical document was made electronic. The term was simply about separating their product from the others in the market. I was having a flashback. I like to rib marketing folks.

    It is the same with the term “Input Management” as well. Marketing convinces people into thinking this is something exclusive to content management, but it is not. You need “Input Management” in all systems, there are just some unique needs in the content management realm. That is for the next blog.

    Reply
  3. Lee Grayson

    Yeah, the first paragraph got away from me. You should have seen the raw version.

    Being asked to blog on this topic reminded me of when Captiva came up with the term “eInput Management”, because there just had to be a designation for electronic vs. physical content. It was as if there was something really different to do after the physical document was made electronic. The term was simply about separating their product from the others in the market. I was having a flashback. I like to rib marketing folks.

    It is the same with the term “Input Management” as well. Marketing convinces people into thinking this is something exclusive to content management, but it is not. You need “Input Management” in all systems, there are just some unique needs in the content management realm. That is for the next blog.

    Reply
  4. Lee Grayson

    Oh yeah, thank you, Allison for helping me get the first paragraph back under control. James, it was good you didn’t see the raw version. There is a reason it was raw. 🙂

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *