We all know that nothing stays the same – no matter how much we might wish it did. In business, there will be new services introduced and unpopular ones discontinued in response to business requirements.
Technology is no different and new applications will need to be incorporated and others dissolved. Equally, the workforce ebbs and flows with new employees to allow access, even internally bringing people in and out of project teams. Change happens, it’s a fact of life, but it needs to be handled competently if the desired benefits are to be realized.
When it comes to reflecting these changes in IT systems, complexity and a lack of process has trumped best practices. Organizations are ready to take action – but the enormity of the situation means many do not know where to start, or even how.
Where does it all go wrong?
We’ve all been there when we’ve arrived bright and breezy on a Monday morning, only to find that a change that has been implemented to the system over the weekend causes things not to work as they should. The result is IT staff, with their backs firmly up against the wall, scramble around the network, making random changes without planning or authorization, in a desperate effort to find and "fix" the fault. The reality is that all of these little tweaks can cause additional problems that may not come to light at first, instead rearing up at a later date when no connection to the original change is made, causing the system to fail.
A more worrying issue is when these changes aren’t identified. There have been numerous examples of how failing to control the process has led to breaches and compliance violations that can be traced back to misconfigured systems.
How can we make it right?
There are many steps that should be followed when defining a change management process. Our top tips for handling this are :
Manual vs Automated
Many organizations still rely on manual documentation of their network configurations. This then means that access requests are also manually processed, which opens up a number of pitfalls:
As this article demonstrates, change is happening frequently and organizations need to keep pace and manage the process completely if they’re to reap the rewards.
Whether you do so manually, or invest in technology to give you a winning edge, time and tide wait for no man. You need to be able to react to changes in your environment, competently, for your team to come out fighting.
Technology is no different and new applications will need to be incorporated and others dissolved. Equally, the workforce ebbs and flows with new employees to allow access, even internally bringing people in and out of project teams. Change happens, it’s a fact of life, but it needs to be handled competently if the desired benefits are to be realized.
When it comes to reflecting these changes in IT systems, complexity and a lack of process has trumped best practices. Organizations are ready to take action – but the enormity of the situation means many do not know where to start, or even how.
Where does it all go wrong?
We’ve all been there when we’ve arrived bright and breezy on a Monday morning, only to find that a change that has been implemented to the system over the weekend causes things not to work as they should. The result is IT staff, with their backs firmly up against the wall, scramble around the network, making random changes without planning or authorization, in a desperate effort to find and "fix" the fault. The reality is that all of these little tweaks can cause additional problems that may not come to light at first, instead rearing up at a later date when no connection to the original change is made, causing the system to fail.
A more worrying issue is when these changes aren’t identified. There have been numerous examples of how failing to control the process has led to breaches and compliance violations that can be traced back to misconfigured systems.
How can we make it right?
There are many steps that should be followed when defining a change management process. Our top tips for handling this are :
Step 1: Graphically build existing workflow processes within your organization. Ideally they should fit IT Infrastructure Library (ITIL) guidelines, or at the very least the organization’s pre-defined processes.
Step 2: Define how changes are requested and what supporting documentation is required. This could be as simple as an e-mail request to a triplicate form that is completed and officially submitted to a pre-determined person(s).
Step 3: Define the change management process so everyone knows what will happen and by when. This should include how changes are prioritized, the timeframes involved, how they can be tracked, how they’ll be implemented. As part of this step, you should also define the appeals process. It should cover how a person is informed that their request has been declined, the reason why it failed and what happens next.
Step 4: If you don’t already have one, establish a change advisory board (CAB). This should include a representative from each area of the business. This team will have responsibility for reviewing all requested changes, checking the change is complete, that it meets business needs, the impact on other areas of the organization both adversely or positively, and finally whether doing so would introduce risks. If declined, this needs to be communicated back to the originator with the reasons why. If approved, the team would then be responsible for communicating the change to those affected by it.
Step 5: Design the change. During this stage it is important that any conflicts or insecurities are identified and rectified to avoid expensive repercussions at a later point. It may be prudent for this role to be split in two with an administrator to verify that the change remains within corporate compliance. This is easier said than done for some changes because in making a change to meet one standard you could quite easily be in breach of another so this role can be key in determining what is and isn’t allowed. There is technology available that can help with this veritable minefield to automate, check and flag potential compliance conflicts.
Step 6: Implement and document the change. In an ideal world, the person who implements the change should be different from the person who designed it to avoid a conflict of interest.
Step 7: Verify that the change has been made, that it has been executed correctly and that only authorized changes have been implemented.
Step 8: Have a backup plan. If a change has been implemented that has had an adverse effect on the system, rather than blindly making changes, it should be reversed, reassessed and re-implemented once the point at which it failed has been identified and rectified.
Step 9: Audit the change process. It is important to check that approved improvements have been made – after all they’ve been identified as beneficial to the organization.
Step 9: Audit the change process. It is important to check that approved improvements have been made – after all they’ve been identified as beneficial to the organization.
Step 10: Regularly reflect on the change management process to identify any sticking areas that can be ironed out.
Many organizations still rely on manual documentation of their network configurations. This then means that access requests are also manually processed, which opens up a number of pitfalls:
Extended costs of manual changes: Manual requests, typically, can take anywhere up to 10 days, which is time that could be used elsewhere. A further issue is the time wasted checking, verifying and implementing unnecessary or duplicated changes that an automated process would have identified.
Risks of something breaking: As the workflow is all on "paper," it is virtually impossible to check all potential break points without automating the process. Sometimes the team will have spent a great deal of time engineering the change upfront for it to be denied by the risk team because approval is sought too late in the process.
Lack of audit and accountability: As everything is on paper, and often hurried, processes will go out the window with paperwork submitted after the change has been implemented, if at all. This can be as basic as having no idea who requested the change or why it was needed in the first place.
Impossible to define and enforce compliance: With just documentation to determine what the organization’s compliance requirements are, administrators are left to use their own personal judgment to determine whether a new rule introduces risks.
Quality of service: As it takes longer to submit and implement changes, the service is poor – both internally and often externally. This can lead to revenue loss – for example, failing to provide access to an online sales system or CRM that has a revenue potential means that every week implementation is delayed, more money is lost.
Whether you do so manually, or invest in technology to give you a winning edge, time and tide wait for no man. You need to be able to react to changes in your environment, competently, for your team to come out fighting.
No comments:
Post a Comment