I use:

Friday, September 29, 2006

Process & Change vs. Sarbanes-Oxley

Sarbanes-Oxley is meant to ensure companies are responsible to the shareholders and that checks and balances are in place to prevent fraud, etc. ITIL is meant to stabilize the IT organisation ensuring reportability and reliability.

I am a firm believer in process. I also have a decent respect for change management and the stability that adds to an organisation's infrastructure and applications. It seems that even though a number of organisations are experiencing a latex-gloved exposure to SOX, they're not learning about ITIL or understanding the impact of a mid-day change. The real problem it seems is that when a cowboy is in a management position, a technical manager, the risk is that they will implement at will. They will implement regardless of the rules and observed best practices of the organisation.

One such folley was the recent change to a corporate WAN that allowed all sites to see all other sites and the resulting traffic was such that at 9:30AM, the networks slowed to a crawl and the plethora of Active Directory servers started chattering. An unwise move to say the least.

It's this sort of hap-hazard management that should be eyed with concern.

A good business has several tools that ensures it functions well, people being the foundation of that. The people hired must embrace the tools and use them wisely to ensure business success with efficiency. The tools I am referrign to are Documentation, Processes, and Systems.

Systems are the hardware, and software that make up the means by which to run the business. This is a combination of infrastucture and applications that serve the staff in fulfilling thier duties and the reliability of these systems is critical. The Processes that are used by business are the standardized methods and manners in which the business is run. It is much like a how-to or manual, but any process that is not documented is prone to change and variance from the standard. This is why Documentation is the key to keeping all of this wrapped together and prevents or removes chance from any person, new or old, making an error because they failed to follow process.

Large-scale operations departments strive for excellence in maintaining systems by counting errors that occur when an operator follows a process. The count can be below 5 for a year in a well-run shop, but effective documentation can push this towards zero.

Processes are as much a path as a rule, but rules do need tuning. Just as in the Systems themselves Changes are welcomed when properly considered, often through a committee or Change Advisory Board (CAB). This is essential, and changes outside of the designated Change Window are only under break-fix or very special circumstances. This is defined well by ITIL, but in truth this is common sense. Those who object are likely developers or cowboys, but this is not meant to offend. A developer (web for example) is often expected to maintain a site and make changes daily, hourly, or more. While this is not signficant for content normally, for fundamental changes or business applications a Change Window helps ensure the application is available when it is needed and outages are planned in a timeframe to minimize the impact on the customer/business.

References:
ITIL, Sarbanes-Oxley Act

No comments: