Process modeling is an activity that goes on in most, if not all, organizations to some extent or other. Even if there is no formal center of excellence for modeling and analysis of organizational processes, there will definitely be a number of groups that perform process modeling on their own. This could be either as a formal effort to manage and maintain their processes, or simply as part of requirements scoping for the solutions architecture for specific projects.
Something that figures in many process maps is data, and mapping which roles and which tasks access data items. On occasion, including data in process maps causes problems, in so far as the person charged with creating the process map perverts the intent of a process map and turns it into a data flow diagram (or more often, some hybrid process flow/data flow diagram). Usually this is when the process map has been created by someone from a technical background who is really more interested in the data flow than the process.
That said, let’s leave this case and consider where data is included as an adjunct to the process flow shown in the process map and does not become a principal operator in its own right. I’ve seen this used very effectively, and in particular for one specific use - to plan and control access to specific data items.
Since a process map shows roles, and shows handoffs of tasks, the process map becomes an excellent way of showing who is accessing what data at what point. Where this becomes particularly useful is when there are regulatory and/or privacy issues to consider. For example, healthcare organizations, government benefit agencies and insurance companies all maintain sensitive data on individuals, and it’s a rare jurisdiction nowadays that does not have some form of regulation on the safe handling and management of personal data. I’ve seen several organizations use process maps as a way of identifying who accesses specific sensitive data as a means to ensuring compliance.
That said, there are a couple of things to bear in mind to use this approach most effectively.
First of all is the need to prioritize. Process analysis obviously takes time, and any medium to large organization will perform a large number of processes – whether these processes are documented or not. So it’s not going to be possible to apply this approach to every process immediately. Therefore, it’s necessary to pre-identify and rank the processes that are most likely to handle sensitive data the most often and make them a priority for analysis.
The second consideration is the management and analysis of the set of process maps. Having mapped the processes that access a particular piece of data, how can you see the spanning set of roles that access them? These are both questions that you need to ask of the process repository that you are using – but it is a question worth asking.
These two caveats aside, using process maps to improve control over access to sensitive data is a valuable synergy for any organization that handles sensitive data, especially data subject to regulation.