Home Our Concept ServicesProducts Shopping Cart Payment OptionsFAQ PrivacyAbout Us Contact Us
You are here: Home > Services > Company Stages > Achieving Operational Readiness

Achieving Operational Readiness

You 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

Dokument your Application Interfaces!

  • Are you sure that after a fast startup you know which application connects where ?
  • And even worse - which testing environment created by copying the production system still connects to other production systems?
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!
Our Product: Documentation Template for Application Interfaces
Our Service: If you do have questions to certain parts of the documentation template, we explain you all the background and why it is important. We can assist you or your staff members to document one interface and enable them to document all other interfaces.

Back to top

Ensure that all daily tasks and duties are assigned, establish IT-internal Operational Level Agreements (OLA's)

... 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!
Our Product: Duties of DBA's and Application Support
Our Product: Operational Level Agreement (OLA) with DBA-Team (including Service-Catalgue)
Our Product: Operational Level Agreement (OLA) with Backup-Team (including Service-Catalogue)
Our Service: We re-organize those comprehensive list of duties according your Organization Structure

Back to top

Conduct a Stability Assessment

(Application- and Database Health Check)

Some time after going live you should conduct an application- and database health check for following reasons:
  • Identify issues early before they cause big problems.
  • Identify issues before the vendor's warranty period expires.
  • If required you can execute recommended changes and reorganizations still on small data volume.
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.
  • Now you still have sufficient space for temporary duplication of all data during reorganization.
  • Due to small amount of data the reoranization process can be done fast!
Our Product: Template: Application Healt Check
Our Product: Template: Database Health Check
Our Service: If you don't have sufficient time to conduct the assessments yourself, we offer to conduct those assessments.

Back to top

Start talking about Archiving and Purging Now!

Why you should start talking now:
  • Input from Business Department is required - decision can take long time.
  • Input from Legal Department is required - decision can take long time, especially if different laws are contradictory.
  • An interfacing system (e.g. Data Warehouse or Reporting System) might screw up your plans .... Due to sub-optimal implementation of data-transfer the "delete" or "drop partition" on your system would be replicated to those systems which want to keep the data longer...
Our Product: Template "Business Requirements for Archiving and Purging"
Our Service: We provide explanation and advise in understanding the requirements listed in this template.

Back to top

Take the First Step on the long Walk to Change- and Release Management

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!

Back to top

A simple Checklist for Production Release and System Handover with Focus on Non-Functional Requirements

Functional 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.
Our Product: Checklist for Production Release with Focus on Non-Functional Requirements
Our Service: A One-Day Workshop / Seminar explaining this checklist to your staff and motivating your staff to use it.

Back to top

First Steps towards Capacity Management

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

  • Use simple scripts, e.g. just inserting daily one row with name and size of database table into anoter database table.
  • Record your job-duration into another database table.

Back to top

Start Watching the Resource Usage and define and measure Indicators

  • Motivate staff members operating those applications to create and daily / weekly / monthly refresh graphs (using simple spreadheet + ODBC-connection)
  • Motivate staff members to try to understand the graphs
  • Motivate or assist staff members in deriving secondary performance- and usage indicators which should remain constant, e.g. "Gigabyte per 100,000 customers", "Gigabyte per 1 million transactions" or "job duration per 100,000 customers".
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

Start Professional Capacity Management and Capacity Planning

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.
Our Product: Documentation Template for Application Interfaces
Our Service: If you do have questions to certain parts of the documentation template, we explain you all the background and why it is important. We can assist you or your staff members to document one interface and enable them to document all other interfaces.

Back to top

Improve your Requirements Engineering Process

Non-Functional Requirements

Non-Functional Requirements are the step children of requirements engineering phase, but they are essential for robuste, stable and managable applications!
Our Product: Requirements-Template for Non-Functional Requirements
More than 150 Non-Functional Requirements!
Our Service: One-Day Seminar "Non-Functional Requirements"
Our Service: We help you in your project to define those important "Non-Functional" Requirements

Requirements Template for Application Interfaces

Our Product: Requirements-Template for Application Interfaces
Our Service: We help you in your project to define the requirements for Application Interfaces in your project.

Back to top

Think about Disaster Recovery (DR) / Business Continuity

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.
Our Product: Decision Template for Selection of Disaster Recovery (DR) Technology
Our Service: We support you in this important decission process to ensure selection of that technology which is most suitable for your situation.

Back to top

Copyright © 2005-2006 Mercury Consulting Limited.