Thursday, 19 December 2013

Lean Methodology at Santa’s Workshop

Did you ever wonder how Santa was able to accomplish the feat of delivering all the gifts in one night with little or no complaints and clearly little overhead? He MUST be following a framework of some type. It is likely that the man in the red suit is following Lean methodology

While Santa is far from Lean himself his workshop operates as a result of efficient processes which minimize waste while delivering quality products on time and at minimal cost. While the origins of Lean are said to come from Toyota Production it is possible a fundamentally similar model was designed by Santa and his devoted team of elves.

While Lean is typically associated with manufacturing, it is being applied to other fields in an effort to improve efficiencies. St Nick already leveraging Lean for manufacturing has taken it to other facets of this delivery service.

The main focus for Lean is on delivering customer value while minimizing waste. In other words, doing more for less. Santa’s workshop achieves this in part by having an endless supply of elves at a minimal expense, gingerbread and candy canes I am told. Even his sled runs on reindeer power which only has stable and feed costs.

Santa, who has an unmatched understanding of his customer base, (you better watch out… you know the song) is able to focus his attention on his processes to constantly improve service delivery.  Santa can maximize value by looking at the big picture rather than the components that drive it such as teams, technology or assets.  As we all know Santa knows what questions to ask and this sometimes is more important the having all the right answers.

The North Pole workshop follows a five-step thought process to guide them through lean thinking.

Identify Value
Ask any kid what the value is on Christmas morning and I am sure you will get the point

Map it out  
Santa and his team have been through a few of these do they have had a chance to get the process done a few times to ensure the outcomes have value 

Create flow
Since Santa only has one night he has to eliminate any component of the flow that impedes delivery of gifts and thus value

Pull
The kids get the value in the morning (provided they were good) in the gifts they receive and full stockings. In other words we don’t assume to provide gifts toll everyone only that are good – thus the pull.

Review
On Boxing Day Santa and team complete a post mortem of the night and make new process adjustments to minimize waste. As Santa puts it "It’s like wringing out the wash cloth a few times over to get it as dry as possible"


Granted there are going to be some challenges along the way….

One challenge is much like a double edged sword. You become more efficient when you discover more issues, so the process never has an end essentially. The commitment to this must be for the long haul so that there is sufficient time to make the improvements and to continue to drive out further areas of waste.

So, why did Santa implement a Lean methodology? Clearly he was looking to minimize costs. His location suggests that the real estate, while in a remote location provided the best value, the elves work for sugary treats. There is also the fact that there is no incoming cash flow. No kickbacks or endorsement deals for this outfit. If you were working for cookies and milk you might be inclined to be leaner as well.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

If you like these articles please take a few minutes to share on social media or comment

Monday, 16 December 2013

Service Management Getting Back to Basics - Conclusion - Wrapping it Together




 
In Part one we talked about looking at your IT team dynamics, thinking about how they worked both individually and as one IT unit. In Parts 2,3and 4 we spoke to some examples of areas which may indicate some holes within the processes these teams are following. Or in some cases not following as well as we may think. While I only spoke to a few examples and there will likely be others we are really trying to get to the "basics" of ITSM. No matter the size of your service management team whether you exist within a SMO (Service Management Office) or you are just starting out with a few people and processes it is going to take some work to identify and fill in some of the gaps that exist.
 
 
You might not get it right the first time. That is ok as long as you can learn something from this and then use that information to improve on what you are doing. You need to start somewhere. Finding areas for improvement in the way that these processes work will enable you to identify some areas where you can improve the customer experience.
 
Being able to clearly quantify where the improvements are will allow you to be in a better position to reach out to your operation and development counterparts to continue improvement initiatives. These IT counterparts will be far more receptive if we can verbalize ways to make the customer happy and streamlining what they already do. Ultimately you will be able to connect with the business to ensure that we are hitting the service delivery mark, but we need to walk before we can run.

 
Start by determining your current state. The real question is that with the processes we execute, have we maximized the value from them yet?

Some key take always from this are:
  • Communication between ITSM components – determine where we win and where we miss the mark
  • Not only reporting on ITSM processes individually but validating these against other processes.
  • What gaps in our processes have surfaced after the review.

Like anything the goal of service improvement is great, but we need some direction to be able to reach out destination. Create a strategy to achieve you targets. Ensure that there are timing points where we can see if we are on target as well as if there are any other concerns
 
We don't always have the answers. Talk to your peers either in your local service management community, the broader global community through social media or feel free to connect with me on either Linkedin or Twitter

Thursday, 12 December 2013

Service Management Getting Back to Basics - Part 4 - Critical Incidents vs Number of Emergency Changes


When it comes to service delivery a happy business makes for a happy support team. What happens though when we see the stats in our reporting which should mean the business is happy but their experience doesn't match up to stats. 

Let's look at a scenario
A few weeks after the monthly IT statistics are published the incident manager runs across one of the application managers in the corporate office kitchen. In the process of preparing their morning coffee the application manager relates his most recent experience of unending emergency changes which involves several after hour deployments the past several months. The Incident manager nods and smiles, she puts a lid on her coffee and then heads back to her desk. While walking back she starts thinking about these weekend issues. She replays the the image in her mind of the application manager motioning his hands like a mushroom cloud. “We didn’t have that many outages last month,” she recalls. Like most service management professionals she pulls up the reporting in the ITSM tool to see what was going on and the metrics look like this:

 
Much as she thought, the volume of Priority 1 incidents was low and did not change from the previous month. She contacts the change manager to get her take on the situation. The change manager indicates that while there has been a slight increase in volume of changes over the past 6 months the percentage of emergency changes has made a much larger increase. The two of them get together and map their stats on one chart which looks like this:
 
Further discussion with the customers confirms that we have more issues going on than our metrics are indicating.

This example highlights once again the need to not only communicate within IT but really take a close look at what are metrics are trying to tell us. Separately, the Incident and Change numbers only told us half the story but combined they are able to show us that we were other issues going on. We could see that while the Incidents were related to the changes the priority was never updated, a good majority of them were left as Priority 4. The Incident manager didn’t realize this mainly because the P4 incidents are rarely reviewed since they are of a lower priority.

To remedy these inaccuracies the Incident and Change Manager will need to review their metrics and identify where the issues lie and what actions will need to be taken to ensure that the incidents are prioritized correctly. Completing these regular reviews will give IT the knowledge to appropriately strategize on service improvements.

Like the other posts in this series we might see a drastic change in the metrics when we relook at how they are generated. That’s OK. I know what you are thinking, “easy for you to say as you type away in your blog about a fictitious situation.” But trust me I have been through this. The key is identifying the issues and taking the next steps to correct the issue. we can explain the anomoly to anyone who is looking at this as an exercise in improvement and communication.

Keep in mind that the only people who are in the dark about the service being provided are IT at this point. The business already experiences the issues first hand.


Check out the conclustion - Wrapping it Together

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn


 

Monday, 9 December 2013

Service Management Getting Back to Basics - Part 3 - Incidents but no Failed Changes?

Did you ever have that friend who scored 99% on the test and someone asked “what about the other percent?” By nature many of us strive to achieve perfection. It is the desire to have things "just right" that in some cases prevents us from moving forward on so many other initiatives.


Think about this example:

You are receiving reports that your IT change success rate was 99% or better for the past several months. Let’s also assume that we are in a position where our incidents are increasing steadily.


I know that the Change Management group is smiling but let's not get too excited yet. Remember we still have that thing called 'the business', that despite your change report is having issues regularly. A closer inspection of the situation indicates that the increase in volume of incidents occurs in a regular pattern. There seems to be an increase on Tuesday mornings. not by fluke one of the organizations largest deployment window occurs on, you guessed it, Monday night.

The questions you need to start asking are:
  • Are the incidents actually caused by the changes?
  • Why these changes are being marked as successful when they aren't
  • Is there a breakdown in communication between Incident and Change when the issues happen so the issues aren't recognized as related?

There are likely others we could ask but let's start with the basics here

I have always been an agent for communication. So the first thing to start with is the working relationship between the incident and change teams. Where can we improve the ability to identify when these incidents caused by changes occur? This is the start and we all know it may not be obvious in the beginning.

Does your change team know that there are issues. Working together to relate these issues will not only help to relate incidents to changes, it will help the Change team to see any process gaps they may have, but ultimately our customers get a better experience down the road. In some cases a weekly review of past changes and incidents can pull up those changes which may not be obvious or have been completed in the past week or so. 

Prepare to see a drastic change in the "successful change" metric. While it may look bleak to some it is a more accurate representation of what the business experience is really like. This will allow you to strategize a way to make improvements once you see what you are really working with. Commit to reviewing this at a regular intervals to ensure you stay on target. 



Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

 

Thursday, 5 December 2013

Service Management Getting Back to Basics - Part 2 - Whats Driving your Incidents

For whatever reason when the topic of metrics comes up on monthly basis, some IT Teams get “nervous” about what they might see as a result. 

Why, you might ask?

The reasons could be as varied as the aplications we support. For some it may be that they are concerned that they aren't doing as well as their IT counterparts, for others it might be that our incident durations are not going down. whatever teh reason may be the fact remains you business already knows how well you are doing. Hopefully your organization is in a position to take these metrics improve on the delivery of service.

For me, I have always believed that there is no “bad” numbers as long as we are able to use them to make an improvement in some way. Reporting should open up our options for what needs to be improved.  
Take, for example, the increased numbers of incidents or requests with no understanding on what is driving this increase. As you look closely into the potential driver know this, there is always something driving them. We might not be able to see it and it may not always be something critical. If you were to ask the teams which are impacted by the influx they may have some theories, and while in many cases their gut response may be accurate, we need to quantify the drivers for this to be able to tackle things appropriately.
Take the story of the frog in the pot of water. If you were to drop a frog in a pot of boiling water it will jump right out. However if you put it in warm water and slowly turn up the heat it will sit in there, possibly until it boils. This may apply to the way that you record and ultimately report on your incidents. You may only have a few of these now but when you look back after repeated business escalations you are shocked as how you didn’t put this all together while it was happening. This is where Problem Management pays in dividends.
The key is that with any improvement initiative is to have some quantifiable information to go back to. It really wont matter if you have a  formalized problem investigation or not if you cant prove out what you are looking at. this is why we say that to make any real improvements you cant do it only in one process. in this case we need to manage our reporting and document it somewhere, perhaps in a knowledge base.

this discussion started out talking about the reduction of incidents and now it sounds like we need to improve in many areas just to make some improvements. it sounds daunting but we need to take a step back and identify what we want to do and keep it simple and iterative. We need to start somewhere and that somewhere is today. We might stumble a bit, but you have to walk before you can use the “Turbo Boost”.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

 




Tuesday, 3 December 2013

Service Management Getting Back to Basics - Part 1 - Start at the Beginning


There are many ways in which you can develop your Service Management process. The best place to begin is to look at current state and perform a gap analysis of where you want to be. This will provide a roadmap for your Service Management journey.
 



 
Think in terms of your IT teams.
 
If you were to poll a room of IT Operations people whether they think that their Service Management processes were mature, effective and providing value you might find two basic types of replies:
 
  1. From people who had been with the same organization for a number of years – they might suggest something along the lines of “things work pretty good, a few years back they were pretty messy.”
  2. From people who had only been with the organization for a shorter time frame– “compared to my last job they seem to be about the same.” They might also indicate that the ITSM tools that they have been exposed to have improved or worsened.

The big challenge is that they did not mention the level of value.
Value you say? It is entirely possible that IT Operations are not even aware what would equate to business value. The prime reason for this is that we do not rate IT success in terms of “how we deliver on business outcomes”. The way that Operations are evaluating service management is from an internal IT vantage point. In short, the processes seem to be working as good as we think they should be working.
 
If you were to ask a room full of Development people you might find there replies might be similar, even if slightly different:
  1. Ask a room of predominantly agile developers and they might tell you that the processes don't allow for the quick deployment of releases that they say would add value to the business
  2. If you asked some fans of waterfall deployment they might suggest a similar sediment as their agile kin although their complaint is that while the processes can handle the timeframe of work there may be higher levels of bureaucracy to cover off the larger releases due to higher associated risks.

While there was mention of value it really only spoke in terms of what we can fix today. It doesn't really speak to any long term value, for example if there are any issues with either agile or waterfall deployment styles.
For both Operations and Development we need to look at our core Service Management competencies and where that fits against deliverables.
An easy way to identify gaps is through the current reporting. What does our reporting tell us (or not tell us) about our ability to deliver service. Some obvious items that tend to surface might be:
  • No failed changes last month. How many did we do? However we still see incidents.
  • Low number of critical incidents versus a high number of emergency changes.
  • Steadily increasing number of incidents or requests with no known driver behind them.

I chose these particular examples simply because most organizations have implemented these processes. In the upcoming parts we will take a closer look at some of these and some remedies for them.


 
 
 

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

 

 
 
 


Monday, 25 November 2013

Success Does Not Need to be a Secret

Whether it is a large issue or some form of a success, by the time we (IT) craft the perfect way to communicate whatever it is, the "it" has long lost its lustre. It may have to do with the way we work within IT. With teams segregated by silos do we find it harder to come together for issues or wins?

The challenge is that IT teams are consistently comparing themselves to other teams when the delivery of IT services is the goal of the greater IT.
The story goes you are as only as good as the weakest link. In this case of the silo IT department we need to look at the delivery of services by team to identify where improvements can be made and then assess what an IT overall service delivery baseline is based on services and then formulate a strategy to attack this.
You can call this IT "sit in" whatever you want under the guise of whatever process you hold dear DevOps ITIL COBIT but the key is .unifying IT under the delivery of services to a business to achieve their outcomes is the only goal you should have

Band together for the issues
IT generally has no issue getting together to solve issues. They are quick to collaborate to find a fix. By their nature they look to solving problems. So why is it that in some organizations that once the issue is resolved the collaborative spirit vaporizes as well? Teamwork is a skill that needs to be practiced. Aside from critical outages where else to you get to work together. An effort needs to be made to find ways to integrate and avoid as much rework as possible. You could be working on similar initiatives which may work against each other. Remember how does this all relate to business outcomes.

Celebrate the wins
For whatever reason this seems to be more of a challenge. Small wins are still wins so celebrate them as well. You may not need to take out a full page add in the local paper but acknowledge the win within the IT team to start. This can build some momentum as well as practice for communicating the big wins

Again this all starts with the decision to move forward as a service provider to your business.


Feel free to connect with me on Twitter @ryanrogilvie and/or on LinkedIn

If you like these articles please take a few minutes to share on social media or comment

Thursday, 21 November 2013

Change Management and the “Gencies”


In addition to the volume of normal or standard changes your organization requires to have completed you will also have to manage the way that  escalated changes are managed. While the above mentioned change types have a consistent way that they are generated there will always be exceptions. An example of this will be the definition of what makes an emergency change and what is simply urgent. In reality each have their own place. Like 2 brothers they may be related but certainly they are not the same.
 
 
Meet Ur Gency

Ur, the younger brother has a tendency to be a bit impatient. You might find him looking at his wrist, even if there is no watch, or tapping his feet. He has an ingrained need to make everything a priority 1 despite whatever is going in around him and despite any other activity priority.
 
 
 
 

Meet Emer Gency

While Emer, the older brother likes to take over when things go a bit outside the lines. Comfortable in chaos, he likes to get all the moving parts back in line and things working again.

 
 
Both brothers like to get things moving as quickly as possible and can work well with teams. But as in life we must ensure that we are moving forward with the right amount of due diligence to ensure that there are no additional issues. This is why we need to clearly define the difference between the two, because much like a parent you won't choose one over the other but will need to manage them just a bit differently.

As changes come in, depending on your service management system, you will need to filter through what is an emergency vs. what requires urgent attention. In some environments everything that is escalated may appear to be an emergency. If you were to verify this with the business they may even say that if this doesn't go in heads will roll.

 
Remind them to breathe…..

Emergencies are likely the result of a break, a critical incident of some sort. Service to our customers is currently unavailable due to some circumstance or event. Urgent changes may be the result of a potential issue. For example if we do not put this in ASAP there will be an Incident.

Understanding and documenting the differences in the changes is important. If we can report on this in some way we may be able to manage or in other cases prevent these from happening again. in the case of urgent changes we might identify that 8 of the 10 times it happens it is the result of a Vendor who has less than stellar communication skills when it comes to visiting sites. Being able to quantify that fact allows us to review that with them when appropriate.

To summarize having a clear understanding on what constitutes an Emergency vs Urgent changes will allow you to ensure that changes are being prioritized correctly and that all input and output processes are performing optimally.


Follow us on Twitter @ryanrogilvie

Monday, 18 November 2013

Demand Management – Like Walking a Tightrope


When I was a kid I could hardly wait for the Christmas catalog loaded with all the newest toys to arrive at my house. I would carefully go through it front to back and all the things that I wanted would get a check mark beside it. Then reality would set in, which of these things am I really going to get? While I was generally well behaved (at least I thought so) my parents were not going to get all this stuff. Effectively this made my parents Demand Management. By comparison this meant that as the kid my role was like that of the business.

The business may also have fluctuating needs with regards to a particular service, so one might suggest that we build for the worst case scenario and then we should be good the rest of the time. to put this in perspective, if you had to transport 10 kids in once a year in a maxi-van for a hockey tournament would you buy one for everyday use? It probably wouldn’t be cost effective. You can always build more to do more, but this approach may also not be cost effective and it will not likely add value. To do that Demand will need to determine what services need to be consumed currently and in the future for varying scenarios.

How do I do this you might ask, the answer – understand your business. You need to know what they "do" as well as the “stuff” that they need to use to meet their objectives. You are also going to have to address potential scalability challenges in the future if the requirements for the services change. The challenge here is having the information available to estimate what the business needs. The risk is that if you overestimate you may satisfy the business service needs but the overall costs associated in doing so. The other challenge is keeping infrastructure costs down but not having the capacity for your business needs.

It really can be like walking a tightrope.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

If you like these articles please take a few minutes to share on social media or comment



Friday, 15 November 2013

DevOps – The Beginners Run Down

“What’s the deal with DevOps?” you might ask yourself. “I finally got my IT team on the same page when it comes to ITIL, now I have something else to walk them through?”

The purpose of DevOps for the most part is to ensure that all the IT teams are working towards the same goal, your business outcomes. Think about your IT team for a moment, specifically your development and operations teams. Culturally they are set up in a way which is counter-intuitive to deliver successful results. There may be an “Us vs. Them” mentality engrained in their cultures, they may even sit in geographically different locations.

You need to crawl before you can run. Make sure that your teams are working together in better relationships before you can do anything else. It sounds simple enough doesn’t it? The challenge is that the whole "Dev vs. Ops" mentality is fairly common. See if you recognize these common complaints.
“Operations always has so many roadblocks for deployments, we never can make the customer happy”
“Development is in such a rush they deploy stuff that breaks after a week”

Any of that sound familiar?
Before teams get too far ahead of themselves thinking about tools that can perform deployments at the speed of light they should think about what DevOps proposes at its fundamental level, IT being on the same page. In effect DevOps should be part of a bigger picture, and may include several frameworks such as ITIL and COBIT to name a couple to get IT where they can be more of a strategic partner. The key is to find the balance from these frameworks and determine what works best for your organization to achieve your business outcomes.

Follow us on Twitter @ryanrogilvie
 
 
 

Tuesday, 12 November 2013

If Only Disasters Were a Video Game - Continuity Management at its Finest?

Nothing gets an organization collaborating together like a minor disaster. Teams that would otherwise not work in close proximity are sharing ideas and working to get the business back up and running. Unfortunately this is not the ideal way to test out our disaster recovery plans, if one has been formalized. If one hasn’t, we say “let’s not have that happen again?  

Now check back with these same organizations a few months after a “disaster” has occurred. Has anything improved? In environments where disasters due to nature are less frequent you may even find that they have reverted into their “we are swamped” mentality and nothing has really improved.

However, planning for the worst case scenario also affords you the opportunity to have a dialog with the business in simplest terms regarding what services are critical and in what capacity.

The overall objective of the Service Continuity process should align with whatever the continuity plans are for the business since they should line up with the business outcomes.

You don’t have a formalized process for this? Or you have a document that is so old that it likely has very little value? It might be time to review with your team on the ins and outs of Service Continuity

Firstly you should have a fundamental understanding of what services are critical to business continuity and what the impact is of the loss of those services. It should also be understood that some disasters may be lengthy so while some business functionality may not be critical on date x or for duration y there should be some additional consideration put in if the disaster lasts for a longer period of time. As an example if your data center is in a location that was swallowed by a sinkhole it may take a significant period of time to restore.

Once we have an understanding on “what” we really need to think about “how” we can mitigate risk or restore services in the event of a disaster. Enter the disaster recovery plan. This document should be able to guide teams to restoring services in a 1-2-3 approach. Depending on the organization there will be varying levels of recovery options available, whether it is a more manual process or if your organization requires you may be bound by your business to have a disaster recovery site which mirrors your data center.

Disaster can come in all shapes and sizes; they do not have to be natural disasters. In the event that your electricity provider had an outage which impacts your data center would you be able to have services available.

Like fire drills you should also test the disaster recovery. This should include everything in the process from notifying the appropriate people that there is a disaster through to recovery and then to reverting back to regular service. These drills will point out potential holes in your process as well as any gaps technologically you might encounter

Regular review of your continuity management process will allow you to be as prepared as possible should the need arise

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

Monday, 4 November 2013

Determining the Value of Bulletproof Availability


Image this scenario; you are in a meeting room with your business. You are sitting across from each other at opposite ends of a table. The topic of service availability has come up. When you ask the customer what expectations there are they reply “Well, we need it all the time”

You then write down a number on a piece of paper which indicates the annual cost of continuous availability, fold it and slowly slide it across the table in their direction.

They look at you for a moment unfold the paper, you can see that there is a slight gasp, and their eyebrows rise, there is a brief hesitation… they reply,
“8 to 5 Monday through Friday will be just fine.”

While discussions like this are the things of satire, there is an ounce of truth in that the customers just want to have their “stuff” up all the time. The key question is how to optimize availability versus cost

How do we go about this effectively one might ask. A good place to start would be to determine what the business really needs:
·         Business hours
·         24 x 7 x 365
·         Can we allot for maintenance outages etc.

Once we know what the business needs from an overall service availability standpoint we will need to understand what risks are present from an unavailability standpoint. Depending on the capability of your other processes you may be in a better position to identify:
·         Volume of incidents which impact the service
·         Monitoring the components within the service or the service as a whole via Event Management
·         The level of architectural redundancy built into the service and it there any single points of failure or weaknesses

There are several ways to identify what can contribute the unavailability of a service; whichever you choose at the end of the day should allow you to strategize on how to mitigate those identified risks. Changes may be required at an infrastructure level if we have single points of failure. There may also need to be changes in the way that IT provides support during incident outages. These along with other factors you discover during the assessment of the service will identify the costs that are associated with the service unavailability

This price tag will be used to balance on what levels of design and support are required for the availability of service we are discussing. The fact of the matter is that nothing is unbreakable, establishing the availability requirements to manage failures for your customers where they make sense is key. This in turn will translate to value to for your customer.

Follow us on Twitter @ryanrogilvie

 

Monday, 28 October 2013

Access Management Process Reviews

It seems that only when the topic of audit comes up do we think about the way we review the overall Access Management process. While it is likely that we regularly review the access to systems (quarterly etc.), should we not be thinking in terms of the access lifecycle. In other words, do we really review the way that access is managed?

To take this back a step, IT organizations in simplest terms are managing the way that access is granted to key systems through 3 activities


  • Onboarding – person is starting new position / role and access is granted via a manual process, or automated with tools and may be verified through a “source of truth” authority in either a team (HR) or an application
  • Changes / Modifications – person is modifying position / role and will require either manual intervention through various managers or again automated through a toolset
  • Offboarding – person is leaving position / role in one way or another and the termination process drives the removal of access either manually or through tools

For the most part validating the onboarding and offboarding (joiners and leavers) may be simplest to define. “Gillian is unable to do her work as access has not been granted” (Onboard) “Desmond has quit, remove access” (Offboard).  

It is the “Changes / Modifications” component that may need to be tightened up from a process perspective. The managing of users and roles across the enterprise, especially large and diverse ones, can be quite complex when there is no underpinning process to govern it.

For example, let’s suppose we have an employee who works in Business Unit “A” and is moving to work in Business Unit “B”.


Questions you should be asking already:
  • When people change roles does your Access Management process discontinue all access from role A and then grant access to role B in a seamless way?
  • How is access to roles validated – the dreaded “just mirror John Smith” can create major access issue?
  • Could lingering access from Business Unit A follow this person to the new role?

You really need to ask yourself if your overall Access Management process is checked in a regular time frame (quarterly, annually)?

Automation
I can already hear some people saying, we have an automated tool that handles all of this. Just because it is automated does not mean it is working or still valid. The process governing how the tool works should be validated just like in the situation above

This process impacts a wide variety of stakeholders, not just the service desk and the users. Any improvements to the process should be reviewed with them as well. It might include:
  • Human Resources
  • Audit and Compliance
  • Business Owners
  • Application Owners
  • and Risk Management to name a few

Remember, finding gaps in the process and mitigating risk shouldn’t be something that is discovered as a result of an issue. Regular process checkpoints should allow you and your organization to proactively move on these before they become problematic

 

Feel free to connect with me on Twitter @ryanrogilvie and/or on LinkedIn
If you like these articles please take a few minutes to share on social media or comment