 |
You are here: Home > Services > Company Stages
> Achieving Operational Readiness
Achieving Operational ReadinessYou did go live! - Congratulations.
Your systems are up and running, and the most important: You are in business. It is still small but growing
. Don't lean back - We don't talk about "optimization" now,
but there are many more important issues left.
Now you need to achieve Operational Readiness as soon as possible!What you should do now:
Write your Operations Manual.
It's not only important for your daily work and the first external audit which you can expect soon, it's the IT-manager's personal "job insurace" and it's also an "educational" lesson to get in future the documentation as part of the delivery.
The vendor's standard manual is usually not sufficient! It does not contain all your interfaces and your individual scheduling!
Don't underestimate the effort! - Check first the
Table of Contents of our successfully sold
Template for an IT Operations Manual".
Back to top
Our 4-page template for documenting application interfaces covers more than 30 operations-relevant attributes for a single interface!
Filling in this template for each interface will significantly improve your understanding of each interface!
Back to top
... and ask for a "positive confirmation" to be sure that your staff really agrees that's their duty.
Detect unassigned tasks before an auditor reports them !
During startup there was one small team and everyone did everything to get it up and running. Now you got several teams inside of IS and IT. The job level and salary was carefully defined, but are you sure that the the detailed tasks are as clearly defined and assigned ?
Did you really clearly define and assign the 60 DBA-duties to System-DBA, Application-DBA and Development-DBA ? Does Application Support Team and DBA-teams have the same understanding about their duties?
You don't understand why you need an "Application DBA" in addition to your DBA-team ? - Then you should really check the following document!
Back to top
(Application- and Database Health Check)
Some time after going live you should conduct an application- and database health check for following reasons:
Your hardware was purchased based on 3-year sizing, and you have plenty of disk space for huge error-files and tracefiles. Your CPU-power can easily deal with sub-optimal program code.
If you need to conduct some data-reorganizations (filesystems, tablespaces etc.) then you should do it now.
Back to top
Why you should start talking now:
Back to top
The high pressure to go live - you had no time to do it according best practice! - is an excuse for a few unplanned outages or data problems in the first production phase.
And as number of customers and data volume is small, the correction / re-processing of errors is not a big issue.
But your next projects should be launched at a higher quality level!
A simple Checklist for Production Release and System Handover with Focus on Non-Functional RequirementsFunctional Requirements are usually tested by Testing Team and during User Acceptance Testing.But that's definitely not enough for a release to production according "good practice". "Best practice" is even a step further, but let's take the first step first! It will take time until you have Change- and Release Management according Best Practice implemented, but there is no excuse for doing nothing until then.
This simple checklist bridges the gap until you implemented Change- and Releasemanagement according Best Practice.
Back to top
You do have plenty CPU-power and disk space for your still small data, and your capacity manager is not hired. And after he joined your company it will take another one or two years until a state-of-the-art, enterprise wide capacity managment system is selected and implemented. And then you need to wait a few months more to collect data. And those data just will confirm that your disks are (nearly) full...
There is no need to conduct Capacity Planning now, but you should RECORD and WATCH the usage!
Start Recording of Resource Usage now
Back to top
Visually reviewing the graphs will early indicate upcoming problems which allows to to initiate improvements before it's too late.
We agree that a professional capacity management system is more efficient - but unitl you get it it might be too late, at least related to undetected problems!
Back to top
This is definitely a madatory long-term objective, but the two simple steps before should allow to avoid capacity problems until you reach this final stage.
Back to top
Non-Functional Requirements are the step children of requirements engineering phase, but they are essential for robuste, stable and managable applications!
Requirements Template for Application Interfaces
Back to top
Even it's now too early for this project, management needs to be aware and allocate money and staff in future.
Introducing a Disaster Recovery Solution is much more than just purchasing one product from one vendor! - And it will - YES, it WILL - increase the complexity of operations!
To avoid underestimating the effort and the impact on operations we recommend to read our Decision Template for Selection of Disaster Recovery (DR) Technology.
|
|||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright
© 2005-2006 Mercury Consulting Limited. |
