Burton Group Catalyst Conference: Roles-Based Access Control Highlights

Today was the first day of the Catalyst Conference general sessions and a number of the sessions that I attended were focused on Identity Management and in particular RBAC. At Big Sky we have always asserted that Identity Management begins with defining the core business processes behind on-boarding and off-boarding users (employees, contractors, etc.) It’s nice to hear from the Catalyst presenters that organizations that have experience in implementing RBAC have a similar point of view; successful implementations start with the process and not by mapping system privileges. Begin at the top and drill down to the details. A summary of the key areas that need to be understood when defining roles:

1. What does each person do in their position? (e.g., DILO study of work processes)
   
2. How do we optimize the processes for that position? (What are the value-added decisions and activities), and then
   
3. Understand what applications that person needs to be effective within that process. (Determine how to best accomplish tasks and share information)

The roles definition will naturally fall out of this exercise and allow the business need to drive the IT implementation. After all, the effectiveness of the roles you define depends on properly matching the right entitlements with the right user in the right position.

Key Takeaways from The Burton Group’s Catalyst Conference.

I managed to gain some good insights today from two Catalyst Conference presentations on cloud computing / virtualization. Both speakers, Chris Wolf from the Burton Group and Mark Templeton from Citrix, emphasized the need for organizations to make deliberate changes to their business processes to successfully implement virtualization on any level. For most large scale change efforts like virtualization, the problems (and failures) often come from the people and processes, not from the technology. After all, technology just does what it’s told. To ensure success, organizations must take a step back from the actual technology to determine what organizational processes are in place now and how those should change in the future vis-à-vis the planned solution. Based on the speakers’ experience, organizations that are most successful with virtualization projects have made a commitment to analyze and change organizational processes as a first critical step to foster solution adoption and to maximize the delivery of business value. The successful implementation of any technology is never an isolated event as it profoundly affects both people and processes. An organization must recognize and plan for this disruption.

"Lean Won't Work Here" -- Post by Mark Graban of Lean Blog

This morning I ran across this excellent post by Mark Graban on Lean Blog that walks through a short history of how organizations have crafted various reasons for why Lean won't work for them. He starts with the automotive industry and ends with health care - but in each case, the industry leaders adopt lean and the laggards fall behind. Each justification for resistance begins with "we're different . . . . ".

Big Sky uses lean principles for many of our clients, but we too have found that there is significant resistance to overt Lean or Six Sigma projects. Many clients are turned off by what I would call "true believers" -- practitioners who are unwilling to let go of by-the-book implementations of lean or six sigma methodology. The practicioners' or consultants unwillingness to be flexible or adapt their approach to the unique client situation dooms adoption of lean in the organization and everyone suffers are a result.

The bottom line, however, is that I have yet to find a process in any organization that couldn't be improved using at least some of the Lean or Six Sigma toolkit. Every client and every organization really is different -- but that doesn't mean that Lean/Six won't work. It does mean that Lean and Six Sigma must be applied differently. The real finesse comes with educating the organization in a way that isn't threatening or dogmatic, but brings them along at just the right pace.

Thanks to Mark and Lean Blog for a great post that I will surely be sharing with many of my clients.

Why Optimizing Decisions is the Most Important Thing You Can Do, Part III

In our last post in this series, we introduced a simple, four-step approach to optimize decisions that we call Decision-Centric Business Improvement. The critical decisions identified through that four-step process represent the resource-intensive turning points of every organization’s growth. These decisions are diverse; some are large: corporate acquisitions, multi-billion dollar procurements, and 5-year strategic goals. Some are smaller: choosing a commodity supplier, making a hiring decision, or choosing the functionality of a software solution. Some decisions are manual, while some are automated. Some require one person; some require groups or even multiple organizations.

The last step in Decision-Centric Business Improvement is optimizing decisions along three angles: strategic relevance, technique, and technology. When optimizing decisions, it is critical that an organization work through each of these angles to build a coherent, balanced approach to the decision in question. The figure below illustrates these three “angles” of decision making.


The Decision Strategy Angle
The first angle of effective decision making is how the decision influences advancement of the organizational strategy. To clearly understand this angle, an organization should isolate the most important strategic metrics of the organization and describe the decision in terms of those metrics. If a decision cannot be shown to have a measurable impact on strategic goals, there is little chance that the decision can be successful.

The right approach in this angle is not to develop a new strategy, but rather to understand the strategy (whether implicit or explicit) and to define a particular decision in the context of the strategy. Traditional strategic planning tools—such as SWOT analysis, multiple forces analysis, or Value Chain Analysis—may be useful in this angle but should be focused on the decision.

The Decision Technique Angle
The second angle of effective decision making is the selection and application of the right tool for the job. A carpenter wouldn’t use a sledgehammer to drive carpet tack; similarly, a good decision maker chooses the tool that is just complex enough—but no more complex—to do the job. In this angle, an organization must understand both the soft and hard aspects of the decision. Hard aspects include the required speed and frequency of a decision, as well as the number of variables involved and whether the decision requires descriptive (backward-looking) or predictive (forward-looking) results. Soft aspects invlude the level of organizational buy-in required, political consequences, human factors, and transparency requirements.

For an automated supply chain decision, an organization might choose to develop a sophisticated algorithm that completes on the fly multivariate analysis. For a one-time strategic decision at a board meeting, it might use a decision tree or a consensus building method. Hypothesis testing, analytic network process, analytic hierarchy process, real options are other approaches that might be used to aid decision making.

The Decision Technology Angle
The third angle of effective decision making is the application of appropriate technology to enable the decision. Most organizational decisions will benefit from better management and distribution of information aided by technology, but not all. Knowing if, when, and how to apply technology is the component of decision optimization least understood and most prone to error.
Good decisions result from a qualified decision maker armed with the right information, delivered at the right time in the right context.

Rather than selecting one-off technology solutions, an organization should understand their “Decision Architecture” – an architecture optimized for effective decision-making. In many cases, this architecture may be comprised of existing systems rather than expensive new ones. Effective organization and adaptation of organizational IT can transform decision-making capabilities in many organizations.

While “hard” decisions—those with many variables or high speed requirements—are the most obvious candidates for the application of technology, technology can be a critical enabler of softer decisions too. Collaboration tools, role-based access control, and innovative application of existing technology (like wikis) can be critical enablers of infrequent, collaborative decision-making. In every analysis of a critical decision, whether “hard” or “soft,” technology should be considered as a important enabler of long-term success.

Seven Steps for Defining Decision-Making Projects

I recently visited a client site to participate in the definition of a consulting project that had been broadly scoped, but that required decisions to be fleshed out in terms of specific project objectives, scope, and key performance metrics.

Most of the management group that would be affected by the project was in attendance, including representatives from logistics, operations, and marketing. They were knowledgeable individuals, well motivated, and responsible for many key decisions in their functional areas. Though eventually successful, it was a long meeting, and we had some trouble honing in to the key elements of scoping the project. To some extent, this should be expected, especially for a complex decision making problem.

Yet, as I reflected on the meeting, I realized that there were certain steps we could have followed that would have been helpful for the task at hand, improved decision quality, and lowered the complexity and time involved in concluding our discussions

1. Define decision making boundaries for the project at the very outset. What is excluded is as important if not more important than what is included inside the decision making framework.
   
2. Reduce the fuzziness in the project definition to the extent as possible through a precise definition of the roles of each constituent group involved.
3. Reduce the decision to a well defined process at the right level in the organization. I have written on this issue in an earlier blog entry.
4. Create project timelines with periodic milestones consisting of broad work structures, with specific attention paid to how the project scope agreed upon would mesh with those milestones.
   
5. Define key performance indicators that would be used to measure project success, and directly link them with final project scope and definition agreed upon by everyone.
6. Create consensus by explicitly seeking inputs for each of these steps from all the key stakeholders present at the meeting.
7. Revisit and re-iterate the steps in the order listed if stuck in discussions that seem to be stalling. Long discussions on performance indicators for instance may be driven more by not having followed the earlier steps (such as defining project boundaries or process level of analysis) rather than by a lack of understanding on what is important for measurement purposes.

While individual situations vary, following these steps will in all likelihood accelerate the project scoping process, reduce fuzziness associated with multiple constituencies focusing their attention on different levels of analysis, and create defined goals and timelines. It will also result in a decision making charter for the project that will have a greater chance for success and goal attainment.

Identity Management: Begin with the Process

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?)