Of Delegation and Tickets
It has been lingering in my mind for too long now but I was not sure whether the hypothesis had any base in reality or was it another arm chair thought. The idea deals with the two ways (I would love to use the word paradigm but will avoid doing so) in which the provisioning product interface have been designed.
Most of the products that I have seen started off with delegated administration in mind where a person (either manager or help desk) needs to perform operations on a single user based on the request that he/she receives out of band (verbally or by other electronically medium like email). The interfaces available to users were for self-service of personal attribute and/or password change . Besides that the idea was that there would be a only a subset of users that will perform the provisioning tasks.
Some how that was a underestimation of the processes already in place in most larger firms. Most of the large firms have a very well defined processes that can be initiated by any person in the firm by submitting either an edocument(like ticket) or a hard-document (signed by manager probably) to a ticket management system or help desk directly. The transition from the manual processes to ticket based system that mimic the manual process may be out of 1) respect for the existing process 2) resistance to and difficulties in setting up new processes 3) legacy of "automate everything" stage 4) any other. We have to understand that even though the existing process may not be the best way of doing things, it (which typically is very specific to a company) has withstood the test of time, laws and audits. At the same time end-user have a good understanding of the interface to the process. Overloading the end-user with understanding new glossary seems so unfair to them when they see the system as an enabler rather than end-all (which the provisioning team may see it as)
The request based system has its own advantages over delegated administration model. It provides an end-to-end tracking of the request generated by the end user in one place which greatly improves the QOS, responsibility and auditing tracking. Most of the delegration based access control that is currently in place is designed to give access to resource so that a help desk person from Germany should not be able to create accounts in US domain. I do not think the lack of provisioning technology was that big a factor to not moving to complete end-user based delegation model which is apparent from the lack of any in-house products at most of the places that I have worked at. Another reason for not moving to delegation based model could be that such a model does not support multiple changes being clubbed in some way for easy tracking and approval.
Now whether the implementation wants to go ahead with business process re-engineering or with implimenting the existing process, an important output of the requirement gathering process should be documentation of the existing process. Most of the time the end-to-end process is not well documented. Even if there are existing training material for help desks, the resource specific documentation (which is typically handled by resource administrators) is not well documented. This resource administration and management process is mostly passed verbally to next generation or is completely absent and relies on creating replica of the "referential" accounts based on the request from the person's manager. This is an audit and compliance nightmare. So understanding of the existing process can give a better understanding of potential holes in the process and may require handling of those issue (for example by setting up a synchronization in place or running weekly reports for access validation). Another important thing to consider after the documentation of the existing process is to consider what part of it can be optimized. At this moment I see that there would be lot of conflict between the vendor's architect and firms architect. The infrastructure at the firms have grown out of changing requirement at firm over 30 years (if the firm is that old and contains MainFrames). While at the same time, most of the product vendors assume a simple infrastructure when they are trying to develop the basic workflow. So, most of the time there would be a custom workflow required for the provisioning the accounts on those custom infrastructure. I was amazed to see the lack of this basic understanding in vendors and their suggestion that the infrasture be changed to fit into the product which would have required multi-million dollar investments.
At this point I am not very sure whether this is a generic principle that can be applied to any implementation or result of a few implementation that I have worked with. Need to do more investigation.
Most of the products that I have seen started off with delegated administration in mind where a person (either manager or help desk) needs to perform operations on a single user based on the request that he/she receives out of band (verbally or by other electronically medium like email). The interfaces available to users were for self-service of personal attribute and/or password change . Besides that the idea was that there would be a only a subset of users that will perform the provisioning tasks.
Some how that was a underestimation of the processes already in place in most larger firms. Most of the large firms have a very well defined processes that can be initiated by any person in the firm by submitting either an edocument(like ticket) or a hard-document (signed by manager probably) to a ticket management system or help desk directly. The transition from the manual processes to ticket based system that mimic the manual process may be out of 1) respect for the existing process 2) resistance to and difficulties in setting up new processes 3) legacy of "automate everything" stage 4) any other. We have to understand that even though the existing process may not be the best way of doing things, it (which typically is very specific to a company) has withstood the test of time, laws and audits. At the same time end-user have a good understanding of the interface to the process. Overloading the end-user with understanding new glossary seems so unfair to them when they see the system as an enabler rather than end-all (which the provisioning team may see it as)
The request based system has its own advantages over delegated administration model. It provides an end-to-end tracking of the request generated by the end user in one place which greatly improves the QOS, responsibility and auditing tracking. Most of the delegration based access control that is currently in place is designed to give access to resource so that a help desk person from Germany should not be able to create accounts in US domain. I do not think the lack of provisioning technology was that big a factor to not moving to complete end-user based delegation model which is apparent from the lack of any in-house products at most of the places that I have worked at. Another reason for not moving to delegation based model could be that such a model does not support multiple changes being clubbed in some way for easy tracking and approval.
Now whether the implementation wants to go ahead with business process re-engineering or with implimenting the existing process, an important output of the requirement gathering process should be documentation of the existing process. Most of the time the end-to-end process is not well documented. Even if there are existing training material for help desks, the resource specific documentation (which is typically handled by resource administrators) is not well documented. This resource administration and management process is mostly passed verbally to next generation or is completely absent and relies on creating replica of the "referential" accounts based on the request from the person's manager. This is an audit and compliance nightmare. So understanding of the existing process can give a better understanding of potential holes in the process and may require handling of those issue (for example by setting up a synchronization in place or running weekly reports for access validation). Another important thing to consider after the documentation of the existing process is to consider what part of it can be optimized. At this moment I see that there would be lot of conflict between the vendor's architect and firms architect. The infrastructure at the firms have grown out of changing requirement at firm over 30 years (if the firm is that old and contains MainFrames). While at the same time, most of the product vendors assume a simple infrastructure when they are trying to develop the basic workflow. So, most of the time there would be a custom workflow required for the provisioning the accounts on those custom infrastructure. I was amazed to see the lack of this basic understanding in vendors and their suggestion that the infrasture be changed to fit into the product which would have required multi-million dollar investments.
At this point I am not very sure whether this is a generic principle that can be applied to any implementation or result of a few implementation that I have worked with. Need to do more investigation.
Comments