Evaluation of the Enrollment System: An Insight of a Student Enrollee

With the discussion of the details of the enrollment system in my previous blog post, I now babble what I have observed that may help in the improvement of our university’s enrollment system. Being a student of our university, I have experienced firsthand the process for the enrollment system just this semester. Among the things that I have noticed and observed, I realized that there is a great difference from your perspective as the developer (or an entity outside the system’s end users) from what the real users usually felt or experienced undergoing the process of the system.

From my previous experiences in developing systems (more specifically in my subjects Software Engineering I and II, Database Analysis and Design I, II and III, and other instances), I have always thought, though this time as a developer or analyst, very differently from what I have thought when I have finally undergone through a system that was developed recently. The thought process for the two roles, developer and user, is very apart or different. At the time I was just developing the systems, I always developed the designs as something the user will find very easy as well as satisfying in catering the expectations of the users. So the system that I (though it was always a team with my fellow classmates, not only me) developed was made with that kind of thought process. The process for transactions, procedures for handling events or cases, etc. etc. are designed thinking for the users good. But since the systems we developed is not really implemented and deployed, there were no circumstances that we get to see firsthand the reactions and effects of the system that we developed. Because that time, it was only our professors or teaching staff that gets to rate and criticize our work, the finished system or even just system proposal. Upon this, I immediately thought how great it was if the college would just try to find a way to simulate an environment where our systems would get to be implemented and used by sample population. The sample users would then create comments or criticize our works. Even if it sounds too imposing and excessive, I think it would be a good chance to learn and discover the flaws we have by just being newbie developers. I also thought that these things must be also part of the role and responsibility of the teacher in-charge of the subjects related to the development of systems since they are only the ones who can impart knowledge and information about how the development of systems would work in a real environment, not only with academic assumptions and imaginations.

Then since what I have experienced during the enrollment (now with the newly developed enrollment system), I have noticed things that may not be perceived at all by the developers or analysts. You see, for me nothing beats customer satisfaction even if it is very cheap, easy to use or “colorful”. My personal policy dictates that customer satisfaction should be placed high above else, even if it is something that is not pretty or presentable, cheap and affordable, and decorated elegantly, as long as it is something that suits to the satisfaction and need of the user, then it is better than any other else (of course, better than the lesser kind, nothing can still beat “perfection”). Back to the issue at hand, even though the new enrollment system have set the procedures organized and uniformed, it may not still be satisfactory as what the developer/s or analyst/s have thought it to be. Although it answers to the problem/s raised that lead to the development of the new enrollment system, the user is not really thinking of such things other than his/her satisfaction with regards to the performance of the system. To help understand this, I will lay out the details of some things I have experienced.

At first, the processes depicted by the new enrollment system do not greatly differ to that of the old enrollment system. It has the same initial steps and same manner of processing the transactions. What is noticeable is that upon finishing the enrollment procedure, enrollees are not required the COR (certificate of registration) at the university registrar but instead, after presenting the necessary receipts and clearance form, the registrar then gives you your COR already stamped “Officially Enrolled”. It was not like that during the previous enrollment system, the previous enrollment system had the encoders give you four copies of the COR, one copy is yours; the others are to be handed to the university bookkeeper and registrar’s office. What I thought is they really do not need much documents any more since the database is now automated and found on the server rather on the steel cabinets and book shelves. I was wrong. This time, you just have to wait at the university registrar longer than you needed to since it takes a lot of time to print new sets of CORs. Aside from that I believe that there is no significant change also found in the system software that would affect to how the transactions are processed, the efficiency of the system, and other factors. The speed to how the transactions are processed still depends on the human operation of the system.

Despite these minor changes I observed, there were cases where failures occur. These failures consist of the system software not producing the right set of information and casually show errors in computing the bills. This causes delays in the transactions leading to the dissatisfaction of the enrollees. During that time, minor delays or interruptions could mean that your time is wasted and your time for enrolling is cut off giving the possibility of being unable to finish the enrollment at that day. But the thing which I considered a major factor that time was the operation of the system involving human participation and control. Aside from the part where you have to get advised with your advisor prior to your enrollment, there are many cases which the system operation is slow and unsatisfactory. The part where you have to pay your bills at the university cashier, submit the COR to the bookkeeper and present the receipts as well as get your copy of the COR in the university registrar are the procedures which disruptions and delays occur, mostly due to human involvement. First, the university having only two cashiers handling the thousands of enrollee is just way too disproportionate. There would no way you could expect a smooth and fast handling of transactions with having just two (2) cashier to face with the floods of enrollees, according to my assumptions, that would reach the number of at least 1000 enrollees per day. Then the bookkeeper would only be one person and the registrar would also be one for each college.

From this situation, it seems the university have expected this so they have thought of a way (maybe part of the new enrollment system) to handle the flood of enrollees. They limited the number of enrollees and controlled the flow to the above mentioned offices. They posted security guards to prevent enrollees entering the CAS building (where the above mentioned offices is located) directly. Instead, they forced the enrollees to climb to the second floor of the building (which was possible from the CAS building design) and go down to the first floor where the offices where located. In this way, the line would be started from the first floor leading to the second or third floor. They thought of this scheme as a way to control the flow as well as to lessen disruptions and commotions from being too overcrowded. But having it that way means forcing the enrollees to expend more time and energy from going all the way to the second floor then back to the first floor. Most of the time, the enrollees are more confused with this strategy since the information was posted only on the first floor. So enrollees that went up to the second floor will immediately see a long line then have no idea where it will lead and why it is being made this way. There was also a tarpaulin that shows the enrollment procedures in the new enrollment system.

That were just some situations that I experienced during the recent enrollment (with the new enrollment system implemented). I suppose the developers for this system can not presume that these things will happen and directly relate to what the user/s might experience. The system itself is not bad and inadequate but moreover, it is how it operated and implemented under the conditions of the university. Otherwise, if the university could provide more service stations (IT term for areas where transaction or service are handled such as cashiers and registrars) and a suitable location good for housing many people. That way, the transaction handling would be swift and smooth lessening the chances for disruptions. It would also be better if the university have a good information system which would support enrollees as well as other people by providing complete and accurate information such as how the enrollment will proceed for enrollees and such. Including these factor may help improve the enrollment system, that I really believe.