How much information and how it is used is a fundamental issue that I always deal with when designing processes: the usual tendency is to put too much information into the process itself (typically because the line-of-business system is so ugly that no one wants to deal with it directly), but that over-replication of data causes problems with synchronization and potentially performance. I’m a big fan of keeping the data in a process to the minimum as long as those other systems can be accessed in some way, and replicating data into the process for three reasons only:
- Data elements that link this process instance to other systems, e.g., an account number. If you want other information about the account, I’d recommend that it come from the system of record, not be replicated into the BPM system.
- Data elements that are passed or displayed to the agent executing a specific step in the process flow, whether a human user or another process/system, that allow them to execute the task at hand. This may be the same information as in the previous case, such as an account number, but may also be instructions such as “call the customer for the missing data on their application form”.
- Data elements that are used to control process flow. For example, if transactions of greater than $1000 in value follow one path in the process flow, and those less than that follow another path, then you need to have a “transaction value” data element in your process.
As Value Wizard points out in Process/information integration, too much information can be just as bad as too little, and can lead to delays and inefficiences while a human operator sorts through a mass of data to find the one piece that they need to execute the task at hand. He points out that we need to be mapping information architecture right along with the process and business architecture, and points out the value of an enterprise architect in ensuring that the information (data) architecture is aligned with everything else.