| Change Manager: | | One role if information technology is to improve business efficiency and to improve staff productivity - and that means change. | | People do not like change and will resist any new computer application on a point of principal, even if it will save them time and make their job easier. | | Our Change Manager must be a business politician to drive change, to drive continual change, to drive effeciencies and to drive productivity. | | Within a few months of any new facilities being delivered, users take ownership of those facilities and do not want to see them change. | | Even when everybody agrees that change is a good thing, change is only good for other people. |
| Project Framework: | | Conversion projects are best treated as a normal development project where the specification of business requirements is well specified in the form of existing source code. | | We are highly skilled in the rapid delivery of demonstrable online services, the critical starting point is the scope of business requirement. | | Existing source code has significant benefits in that the pedantic detail of field size and permitted values can be derived by inspection or automation. | | A potention problem is that the old system design may unduly influence the user interface. | | It is very difficult to design a simple solution and where hundreds of existing user interfaces exist it is too easy to replicate what existed into an overly complex service. |
| Computing in the cloud: | | Our web-based application services have considerable benefits over old windows-based systems that should not be influenced by a conversion project. | | Application in the cloud are scalable to any number of users with only modest database administration costs. | | Applications are free of any dependent computer of smart phone restrictions - any browser on any computer with any operating system can be used. | | Applications may be used by authorized people from any location; in the office, with a client, one the road and from home. | | Costs are reduced by eliminating the need to install software on computers, by making certain that all user are always using the very latest version of the application and automating business continuity from multiple remote data centers. |
| Little Changes: | | We tried the big bang type of business change and did not like the emotional backlash, so all projects are built as a large number of small steps. | | The first step is he hardest, so it must be the most important and with the least disruption to existing methods of working. | | Once a service is operating, day-by-day improvements can be slotted in, each too small to require retraining, but evolutionary over time. | | Our Change Manager is the master of dressing-up strategic changes as little changes, not a a way to deceive, but as a way to implement without disruption to the business. |
| Multiple Language Support: | | Built into the infrastructure of all our web application services is support for multiple human languages. | | Implementation is generally where each authorized user selects the language that they choose to work with and this is stored in their user profile. When that user signs in, the user interface uses the human language that they have pre-selected. | | Many people using different human languages can use the application service at the same time and share data as if they were all using the same human language. Multiple language support carries no processing overhead as only one language file is loaded to process any one transaction. |
| Translation: | | Data is stored in the database in the language that the data is entered. | | Business notes and comments can be translated into another human language in a simply way that may be adequate for internal business use. Translation is not to legal quality and should not be used in external correspondance that is subject to terms and conditions. | | Management information may be generated in different languages from data stored in the database, but that information canot be translated again into another language. True round-trip translation facilities are not provided. |
| | | Conversion: | | We have had a lot of experience in converting Microsoft Windows-based client-server systems to modern web-based application services. | | Where existing Visual Studio, Visual Basic or C++ source code exists with Access, Sequal, ADO or SQL Server; then a good deal of automatic conversion can take place to generate modern web page and MySQL specifications. | | Dialogue flow can be hard to visualize from source code, so some test data can have a dramatic impact in bringing the system to life so behaviour can be fully understood. Where the old and new applications can be demonstrated side-by-side, then the scope of business requirements is well and truely verified. |
| Change Data: | | 1. Unique ID | | 2. Date of submission | | 3. Change Owner | | 4. Initiator of the RFC (if not identical with Change Owner) | | 5. Proposed Change priority (e.g. Very High (Urgent Change), High, Normal, Low - may be overruled by Change Management during Change assessment) | | 6. Description of the Change being applied for | | . 1. Summary description | | . 2. Business case | | .. 1. Reason for the Change to be implemented | | .. 2. Costs | | .. 3. Benefits | | .. 4. Consequences if the Change is not implemented | | .. 5. References (e.g. to a Problem Record triggering this RFC) | | . 3. Business areas on the client-side affected by the Change | | . 4. Services affected by the Change | | . 5. IT infrastructure components (CIs) affected by the Change | | . 6. Technology aspects (is a new technology being introduced?) | | 7. Risks during the implementation of the Change | | . 1. Identified risks | | . 2. Counter-measures (e.g. reversion procedure) | | . 3. Back-out strategy for the case of a failed Change implementation | | 8. Predicted/suggested time schedule for the implementation | | 9. Estimate of resources for the implementation | | . 1. Required personnel resources (from which areas?) | | . 2. Estimated work effort for the required personnel resources | | . 3. Cost estimate (itemized for bigger Changes) | | 10. Statement as to whether a budget is allocated and cleared for this Change | | 11. If applicable, index of additional supporting documents (e.g. the Service Design Package for major additions or modifications to services) | | 12. Approval or rejection | | . 1. Date | | . 2. Person/ body in charge of the approval (Change Manager/ CAB/ EC) | | . 3. Change reviewers | | . 4. Priority assigned by Change Management | | . 5. Restrictions | | . 6. If applicable, reasons for rejecting the RFC |
|