Friday, October 14, 2016

Conversations from Summit- Security and Asking Why?

Sitting on a plane flying home from Tampa is a great time to reflect. I have always enjoyed Summit for a variety of reasons beyond the sessions like...
  1. Reconnecting with long-time consulting friends, vendors I have known longer than I have been married, former students, and clients
  2. Inspired  conversations about what we do, how we do it better, and why we are so collectively passionate about how software can help businesses grow and individuals prosper
  3. I always leave having learned something, some years it is functional/technical know-how and other years it might be a perspective change or a piece of software that solves a common issue
One of these inspired conversations happened this week when I was sitting with a group of MVPs and others in the Mekorma HUB discussing who is trusted in an organization.  So I wanted to share a few of those points, and expand the question a bit.

It is not uncommon for us (as consultants) to get requests to restrict security for users.  Totally common.  What gives us pause from time to time is the role of some of the individuals that are being restricted like...

  • Payroll processors
  • Business analysts
  • HR managers
  • Financial managers
It is not so unusual to have security in place to protect processes and demonstrate the process control that auditors like to see in organizations.  But sometimes it is the specifics of what is restricted that makes me think.

For example...
  • With payroll processors- restrict their ability to see any dollar values
  • For business analysts- restrict their ability to see certain financial numbers, or detail information behind them
  • For HR managers- restrict their ability to see payroll information
  • For Financial managers- restrict their ability to use reporting tools, like Smartlist
I don't mean to suggest that there are not valid reasons to do all of the above.  But I do think that if you find yourself doing (or requesting these things), you should pause for a moment to ask "why" and do a little due diligence on the goal.  Often times, when we have these "pause" conversations, we find that the reason falls in to one of two primary categories: trust or training.  Here are some of the specific reasons we hear, categorized accordingly..

  • Trust
    • Concerns that employee will not be discrete/act professionally with information
    • Executive level edicts that certain data be restricted to limited individuals
    • Internal behavior that suggests employee would be upset with what they learn
    • Employee is new to organization
  • Training
    • Concerns that the reporting that will be created will be incomplete/invalid
    • Experiences where individuals "messed up" the system inadvertently
    • Wanting to avoid unnecessary questions or "busy-body" behavior
In the cases above, I encourage organizations to address  the root cause.  Limiting access doesn't address these gaps or behaviors, it just eliminates the opportunity.  If we are in the business of growing employees (which I think all organizations are), we need to have these coaching conversations, provide the training and guidance they need, to be better professionals (which in turn benefits the business in not only outcomes, but also in loyalty).

More conversations from the Summit coming, but let me know your thoughts on this one.  Do you agree?  Disagree?

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

No comments: