How will things change?

By Jon Lewit, Asst. VP for Technology & Information Systems

We Are Moving From The Customized to the Generalized
The eighty or so current student records screens are the result of local requests, and in some cases the data is pretty tightly crammed in. Banner screens were developed along functional lines, and information on one of our screens may well be spread over several Banner screens. There are hundreds of screens. There will be training on what things are called and where to find what you need. We can create 'workflows' that automatically take you from screen to screen to perform a common task (e.g. Creating a new student) but we will not be re-writing any Banner screens.

Banner is a Much More User Centric System
As mentioned earlier, Banner is driven by hundreds of validation tables and rules that define what actions are allowed. If you register during this time period, then you are under this schedule of charges. If you do not have this prerequisite, then you cannot take this course, etc. This will be different than the way we currently operate in several significant ways:

• The functional areas (Records, Admissions, etc.) and not the programming staff in Computer Service write the rules that drive the system. If there is something not quite right in how registration is working, the Records office (with assistance from the programming staff) will have to figure it out.
• If there isn't a capability in the system to address a local policy or procedure, more than likely that procedure will either have to change or will have to be addressed outside of the system
• It will be very burdensome to implement customized requirements (e.g. the limit on the number of graduate credits non-matric graduate students can take will be defined globally for the campus, and not 'adjusted' for individual departments)
• In general, changes to the base system are not programmed locally, but are added to the system by the SICAS Center. Our local directors will be participating in SUNY-wide 'Functional Area User Groups'. These groups meet regularly throughout the year and they decide what changes are of general importance and significant enough to be requested from the SICAS center (Student Information & Campus Administrative Systems - a SUNY-system wide group that develops common software and services for those campuses using Banner in New York). The SICAS center, in turn, figures out what it can attempt during the coming year and schedules the tasks accordingly.

While there are areas where our current system is more capable than Banner (parts of my.newpaltz.edu do not yet exist in their Web system) overall Banner is more complete than what we now have. The burden of effort and responsibility in some areas will now shift from the programming staff to the users. Banner is capable of doing course pre-requisite checking, multiple refund periods, multiple grading periods, highly sophisticated workflow processing, document storage, automatic electronic communications, etc. The effort will be in setting these pieces up, and in many cases the functional offices may not have the resources or desire to do much more than they are doing now.

Under Banner, Some Changes Will Be Externally Driven
Banner is still being actively developed by SCT, with minor releases every three to four months, and major functional improvements every two years. Nothing will stand still anymore. And as mentioned above, the SICAS center is also enhancing the system based on campus requests and these are often rolled in along with the SCT changes.

The good news is that the system is constantly being enhanced and we can expect that in the fullness of time significant issues will be addressed. The down side of this is that we will be in a near constant state of implementation. The Computer Center will have to invest a significant amount of time into rolling out new releases of the system as they become available. It also means that our user offices will have to invest time testing and learning the new releases before they are moved into the production environment. In addition to the amount of time and effort involved in keeping up, another consequence is that we can afford to make very few, if any, changes to the base system because we will have to re-install and re-test our local changes with every new release. If we tinker too much, the whole process will become unmanageable.