One element of the project to move to a single sign-on for our large community college is to document how account creation/removal, authentication, and resource access allocation works throughout our school. These logins could be to our own Banner database or various outside or other internal services and file sharing systems. We have a fairly deep questionnaire that is being distributed to collect data. The small group I'm in is assigned to document, organize and, if possible, visually model the results.
I am very new to the concept of BPM and have been learning how some basic business processes are modeled start to finish, but I am at a loss when it comes to understanding how one aspect of many different processes can be modeled in a consistent and useful way.
Any guidance would be welcome.
Thanks,
Ric
M. Zschuckelt on
Hello Ric,
Trying to understand the scope of your project, so I put it in my words:
1. The overall target is to achieve single-sign-on (SSO) for all the applications in and around your college. So you are successively going to to hook all those applications on to a central LDAP service or the like.
2. You need to define standard procedures for the administration of the application privileges contained in the LDAP server, possibly individual procedures for each application, because application specifics may require different approval procedures by application owners or other roles involved in the application administration.
If I got this right, here are some modelling hints: Use "Roles" as an abstraction for people acting in your processes. Roles may even be specific to the process. Roles are like "hats" people put on when performing in the process. One person will assume multiple roles in different processes or even the same process. But observe segregation of duties, so you don't have the same person approving it's own requests, if that is inappropriate in your business. Another abstraction you can use is the "Position". It represents the smallest organizational unit, i. e. an employee or a title an employee would print on his business card, or a budget item on the payroll, whichever way you want to look at it. You assign a number of roles to the position. The sum of their descriptions and process steps the role performs in gives you something like the job description for the position. Using the positions you get an idea, which roles you want to lay into a single persons hands and what processes the position contributes to and how.
Roles may have different relationships to the process steps. See also http://en.wikipedia.org/wiki/Responsibility_assignment_matrix
; most important is the "is responsible for" relationship, which indicates the role actually doing the thing.
The roles are also candidates to be represented as user groups in LDAP, where people perform in your administrative applications.
Does this help you?
Regards, M. Zschuckelt