Many schools decide to switch nodes of the system, not because they have thought clearly, but because the existing system is simply unsustainable. The certification server has been crashing more frequently in the start of the school season, financial reconciliations are becoming increasingly variable, and the support of manufacturers is becoming slower, while the insurance evaluation begins to point out problems.
Before changing the system, there are three things to think about.
First thing: what the pain points are, needs to be diagnosed first. The problems of the system often combine multiple questions but they have similar manifestations.——All complaints.——So it's easy to be seen as a generality."The system's not working."The real diagnosis needs to be distinguished between performance problems and the core bottlenecks of peak periods; structural issues, multi-schools, multi-operability shopping sites where existing designs are not supported at all; transport problems, too many manual operations, poor monitoring and inefficient delivery; and process problems, where financial reconciliation mechanisms themselves are poorly designed and require manual repair on a monthly basis. Different types of issues correspond to different selections: performance issues focus on indicators and maturities, architecture issues focus on the expansion and modularization of the technical architecture, transport issues focus on the observability and automation of systems, process questions focus on functional compatibility with existing school methods.
A specific diagnostic method is to collect the manifests for the past six months to one year, and to make a breakdown by type of complaint."Cannot access the Internet after charging"The high proportion of complaints of a class indicates problems with the link between the charge and the strategy; if"Authentication failed"Complaints are concentrated in the school start-up season, indicating that capacity to process and deliver is a bottleneck; if"Financial variances"The type of complaints is stable every month, indicating that the reconciliation mechanism itself is problematic and not systematic.
Second thing: The new system is designed ahead of time to switch windows and parallel strategies."The old system is disabled when the new system is online."This is done every day. The switch must be a smooth transition process. The two systems running simultaneously in parallel, the data keeping up and running in the same time, the students ' charging, changing the set, billing records in the old system, and real-time syncling to the new system. If parallel design is not reasonable, there will be a data fault when switching: students are charged in the old system, but the billing has been switched to the new system, leaving no balance.
The length of the parallel period is assessed on the basis of actual data levels, not a week or two. The suggested criteria are that the new system ' s data be fully aligned with the old system for three days before it is formally switched to key indicators (account numbers, amounts charged, consumption records). If differences occur, they need to be clearly itemized over the three days and cannot be forcibly changed with unresolved differences. If complete consistency is not achieved within three days, the data synchronization mechanism itself should be addressed in parallel periods rather than issue lines.
Third thing: if the existing crews are able to match their capabilities when the new system is online. When any new system of billing is on line, the team needs a learning curve: how the system's alarm system is configured, what the path for common malfunctions is, which operations can be done in the system interface, which must be handled through backstage commands, where the logs are viewed and what the different types of questions correspond to the check entrance. If the crew has not had previous experience with the management of such systems, there will be a lot of access early in the network."The system itself is fine, but the problem is caused by an improper operation of the carrier."The problem is almost the same as a real failure, and it's completely opposite and wasted a lot of time."Students cannot be certified"The complaint was checked by the transport team for a whole day and it was finally discovered that the engineer accidentally made an extra space when he configured the Radius key.
It is recommended that the contract require a vendor to provide no less than one week of on-site transport training, for example by an engineer actually responsible for the project, rather than a pre-sale or market worker from the manufacturer. The manufacturer is also required to provide complete maintenance manuals and fault-checking tree maps, not general functional descriptions, but customized guidelines for the school’s network environment.