Agenda - Why Change Management

  1. What is Change Management?
  2. Why do we need Change Management?
  3. The Basic Components of Change Management?
  4. FENIX/400 Automated Change Management System
  5. Conclusion


What is Change Management?

Simply put, CM is the process we use to manage and control changes to computer software. This includes the development, installation, and maintenance of our application systems. The process of CM, therefore, helps us with the following:

  1. PLANNING
    The planning and co-ordination of approved in-house requirements.
  2. MANAGING
    Managing the application of these requirements.
  3. TRACKING
    Keeping track of all completed tasks, work in progress, and pending user requests.
  4. SECURITY
    Ensuring that the security and integrity of our systems are not compromised.
  5. DISTRIBUTION
    Managing the distribution of our application systems in multi-site installations.
  6. VENDOR APPLICATIONS
    Managing the installation and update of vendor applications.

>BACK>


Why do we need Change Management?

  1. CONTROL
    Establish complete control of all our software.
  2. SECURITY
    Improve security of our systems reducing the risk of system failures (hence less downtime resulting in a better service to our users and, therefore, our clients).
  3. IMPROVED AUDIT
    Simplify the task of auditing the system as well as satisfying audit requirements.
  4. OPTIMISE
    Co-ordinate and optimise the allocation of resources available.
  5. QUALITY ASSURANCE
    Improve quality assurance.
  6. TURNAROUND
    With optimised resources and improved quality assurance, we would provide a better and faster job turnaround, again, improving user service.
  7. REDUCE COSTS
    With the high cost of software and software development, a good change management system would help in keeping costs to a minimum.

>BACK>


The Basic Components of Change Management?

  1. LOG USER REQUESTS
    The system should provide a means of logging and documenting all user requests.
  2. BLOCK UNAUTHORISED ACCESS
    A means of blocking all unauthorised access to the system software.
  3. MULTIPLE/CONCURRENT MODIFICATION
    Identify, inform, and track all system components being modified by more than one programmer, and/or not permit multiple access to the same object.
  4. SATISFY AUDIT
    Should meet all audit requirements.
  5. SIMPLIFY PROGRAMMER TASKS
    Should not be so complex to use so as to complicate further the programmer's tasks. It is when this happens that programmers begin looking for means of abusing the system and finding short-cuts to production.
  6. COMPLETE TRACKING SYSTEM
    The system should provide a complete history of all system objects including a means of recovering archived objects.
  7. EMERGENCY
    The system must cater for emergency modifications and provide an audit tracking facility for emergency modifications.
  8. DISTRIBUTION MANAGEMENT
    Should provide a means of securely and efficiently managing the distribution of application system upgrades to other sites in a multi-site environment while maintaining full version control.
  9. SIMPLE TO USE
    Should be easy to install and use. The more difficult a Change Control system, the more likely will programmers attempt to find ways around the system.
  10. COST EFFECTIVE
    A good Change Management system will always be cost effective.

>BACK>


FENIX/400 Automated Change Management System

FENIX/400 Change Control System is designed for the IBM AS/400. We recommend the system as it provides a complete easy-to-use Change Management package with excellent security and audit features.

The main attributes of FENIX/400 are as follows:

  1. EASE OF INSTALLATION AND USE
    Installation and training can be done during the course of 1-2 days (installation 1/2 a day, training 1-2 days depending on the size of the installation).
  2. ANY LIBRARY LIST STRUCTURE
    FENIX/400 is designed to cater for any library list structure and, therefore, can be installed in almost any installation without having to modify existing library structures.
  3. UNLIMITED NUMBER OF PROJECTS
    FENIX/400 provides a task/project logging facility for any number of projects. Every task is separately linked to a text editor for full project documentation.
  4. ACCEPTANCE TESTING
    Caters for secure and multiple acceptance test areas.
  5. MULTIPLE ENVIRONMENTS
    Any number of applications managed by any number of departments may use the system on the same machine without interference from one another.
  6. MANAGEMENT FACILITIES
    Provides project management and project status facilities with at-a-glance enquiries and lists showing who is working on what at any point in time including outstanding tasks in development, in user acceptance, scheduling information, completed tasks by date, time, etc..
  7. NON TECHNICAL OPTIONS
    FENIX/400 also provides non-technical librarian options for system administration such as project logging and documentation, programmer authorisation, object movements to production etc, without having to depend on technicians. Indeed, this is a preferred practice from the point of view of audit and security.
  8. EMERGENCY MODIFICATIONS
    FENIX/400 provides for emergency modifications while also providing a full audit of all emergency changes made to the system.
  9. ARCHIVE MANAGEMENT
    As well as keeping a full track of all historical object data, both on-line and off-line,previous versions of objects may also be retrieved via FENIX.
  10. AUTOMATIC PROGRESS LOGGING
    Although programmers continue to work as before, every stage made through the development cycle is logged with a date and time stamp.
  11. AUTHORISATION FORMS
    Promotion authorisation forms may optionally be printed showing all objects required for promotion from development to acceptance to production.
  12. AUTOMATIC AUTHORISATION
    FENIX/400 automatically updates production objects with the correct authorisation hence reducing system failures due to authorisation problems. This also speeds up the promotion of completed tasks to production without any compromise to system security.
  13. AUTO RE-START RECOVERY
    Whenever a system failure occurs, no special procedures have to be run to recover.Programmers simply continue from where they left off.
  14. AUTOMATIC HOUSE-KEEPING
    The system automatically clears programmer libraries of objects and/or sources going into the acceptance libraries for compilation, therefore, freeing up valuable disk space.
  15. CASE INTERFACE
    FENIX/400 provides an interface for the logging and movement to production of objects and/or sources generated by 4GL systems.
  16. DISTRIBUTIONThe distribution of production objects and/or sources to any number of installations is made simple and efficient and may be carried out by non-technical personnel. Distribution may be done via magnetic media or direct communication link.
  17. COST
    We believe that FENIX/400 at a modest price will not only pay for itself in the short term by reducing software maintenance costs but will continue providing the added value long afterwards.

>BACK>


Conclusion

In conclusion, we have to decide between having:

  • TOTAL CONTROL at no cost.

OR

  • TOTAL CHAOS at any cost.

The development of software is very difficult to co-ordinate and, unfortunately, has no magic formula for success. What is certain however, is that success is based on sound and practical management throughout the project's lifetime and well into implementation. It should therefore, be in our interest to study and take advantage of whatever development tools are available to us.

>BACK>