Big Sky Thinking

In one of our earlier entries, "Identity Management: Observations from the Trenches", we discussed some of the pitfalls of rushing to implement an Identity Management solution without looking at data quality, data requirements, and starting with a point solution instead of an enterprise approach. I wanted to add to that discussion and emphasize the importance of knowing your processes before you implement identity management projects.

Many times a project can seem straightforward both technically and organizationally, but often there is something you don’t know that will send it to the scrap heap. Let’s look at the following example: a company wants to improve the time to provision new hires into their non-connected systems by sending an automated email as soon as the user’s identity is created in the directory. Based on the way the process runs today, the client believes they can save two weeks in new hire provisioning, and they are eager to cash in on this golden opportunity. Fair enough.

At this point, the development team is ready to start building something immediately. The core infrastructure is already in place, we just need to slap in some workflow with emails and we are golden, right? Not so fast. It turns out upon further evaluation, that the organization did not clearly understand their onboarding processes. The assumed bottleneck, that staff were not receiving notifications of a new hire promptly, was not really the problem. Instead, the delay in the process was caused by the manual assignment of the user’s id by another department. This id was required for all provisioning activities, including creation of the user’s identity in the IdM system, which means that system-generated emails buy us nothing; they simply automate a part of the process that is already working fine.

So what are our lessons learned?

a)Bring key stakeholders (business owners, corporate staff, etc.) into the early planning meetings and touch base with them regularly

b) Start by mapping out your processes from recruiting through creation of the user identity in the directory (work with your stakeholders to complete this analysis)

c) Identify key data that are needed (user id, etc.) to support the project, where the data reside, and when they become available along the process

d) Validate your process maps with your stakeholders. Step everyone through the process and discuss:

a. the process steps (Are they correct? In the right sequence?)

b. process timing (How long does each step take?)

c. data flow (What data are available when?)

d. process bottlenecks (What are the slow points in the process? Rank them in terms of time consumed.)

e. process dependencies, and identify any process changes that will be required (Can we get people into the ERP system sooner? Can key data fields be entered earlier? Do we need to change the way approvals occur in the process?)

Labels: business process, directory, edirectory, governance, Identity Management, provisioning

James Taylor, who writes one of the best blogs out there on automated decisions, posted a good definition and explanation of "Decision Services" that is worth a read. James's definition of "decision service" is "a self-contained, callable service with a view of all the conditions and actions that need to be considered to make an operational business decision."

He goes on to explain some of the conditions that a decision service must meet. My favorite addition is: "not only should [a decision service] respond sensibly when it cannot decide, it should ensure that enough context is returned as to why it could not decide to assist a manual process."

That's an excellent point that gets at a key concern that some of my clients have about automated decisions--a perceived lack of control or transparency about how decisions are made. This is particularly important to clients that have compliance responsibilities such as government regulation, Sarbanes-Oxley, or HIPAA. It's critical that those organizations have the ability dramatically increase decision speed and quality through automation, while maintaining the ability to provide explanation and justification to external authorities, and/or fairness to their stakeholders or customers.

Thanks to James for a great post.

A few weeks ago we posted on using visuals to make decisions, and how it can help in both conducting manual decision-making processes and understanding automated decisions.

Today I ran across this post at BoingBoing by way of Seth's Blog. It's a periodic table of visualization methods that depicts 50+ techniques and categorizes them by type and appropriate usage. It's a pretty slick graphic by itself, but the authors have really dialed up the cool factor by providing examples of each item on the table when you roll over it with your mouse.

I'd highly recommend passing this link around the office, even for those of you who tremor at the mere mention of high school chemistry.

Labels: graphics, models, visuals