I was on day shift all last week for meetings with our primary software vendor. We are in the beginning stages of upgrading our software. While with the same vendor, the new system is built new from the ground up1 and in many ways fundamentally different from what we have now. These type of upgrades occur only a few times in the life of a call-center. With emergent technologies, it is a necessary upgrade. We must do this or jump to a whole new vendor which would be a whole a lot more money than just an upgrade. And a new system is always rough on the end users. lol

The process itself wasn’t bad albeit a bit tedious at times. I had to flex my hours for the week to accommodate the vendor schedules. While a hassle, not the end of the world and well worth it considering the impact this will have on myself (and others) as the end users. Only 2 big surprises so far. The first surprise was a functionality problem. The new system while more robust created a more tedious format for one of our daily (and constantly repeated) functions. The architecture of the new system would not allow a fix no matter how much money we might have thrown at them. We were upset because this was not properly demonstrated during the initial investigative phase. Needless to say this caused some tense conversations. My big boss happened to be in the meeting at the time and was also not amused. But, while unfortunate and most definitely annoying, it was not a deal breaker. It does mean some training issues are involved and some headaches for the end users for the first few months.

The second surprise came from a sub-vendor regarding hardware upgrades and would be a total deal breaker. The software to control the hardware had to be modified and the modifications were just not going to work for us. The sub vendor was a bit miffed and seemed completely at a loss that what they had designed wouldn’t work for us. It’s always funny watching folks who don’t routinely use the software they create get frustrated when the users don’t like it. There are certainly two sides to that coin but at the end of the day the user-base should be happy, or at the very least still be able to do everything they need to do. In this scenario, it just so happens some of SF’s daily operations are unique and created a conflict. Naturally, the fix requires more than just some drop-in code. The interface will have to be almost completely rewritten. From my perspective, I see it as poor programming as the issue deals with API calls and they wrote an interface with no flexibility. It was all or nothing and as-is, it was nothing for us. lol The good news is the vendor wants the contract bad and will bend over backwards to make it work within the budget constraints. Granted some money issues will be discussed but that is way above my pay-grade. I think we’ll end up with a decent fix.

Don’t get me wrong, I’m not bitching or even unhappy. I’m actually glad I got to be part of the process. Being a bit technology-inclined I had a higher-knowledge base to work from. And while I may not have understood some of the hardware terminology, I was never once lost in the process. Both my coworker and myself pointed out some real issues along the way and the main vendor was very responsive to our needs.

In the end, the project will probably remain on budget but just barely and there will be some serious code re-writes to accommodate what we need. The rewrites are going into the base code which means less headaches anytime a system patch or small upgrade is put out. As for us, there will be some definite training issues and adjustments but overall the upgrade will make life easier for us. The project won’t go live until early 2014 so still plenty of time to hammer out the details.

I was very happy my boss included us because often times a lot of very important decisions get made about software w/o the end-user being consulted. Our input helped avoid some major problems that would have been over-looked otherwise. This of course, saves us a lot of grief being stuck with a product that only partially meets our needs.

  1. new as in newer than we have now but still mature as a product []

2 thoughts on “Upgrades”

  1. I don't know if this will help but just throwing it out there for you. If the first surprise is a repetitive action event, there is a product called Hot Keyboard Pro that might help. It allows you to create macro scripts and can focus on whole window events, mouse position events, and many others. I use it to clean up a .dat file dump from a mainframe to slice and dice in Excel for multiple sheets and pivot tables for data analysis. http://download.cnet.com/Hot-Keyboard-Pro/3000-20

    Due to the nature of our access to state/federal databases, we cannot install or run such things. Many of the functions we run are repetitive but the variable is different every time. Thanks for the tips though. I appreciate it.

  2. I'll tell you a little secret. Most record management systems and I mean almost all of them run on MS-SQL and Access. Which means they're seriously easy to modify.

    In the rate instance on the enterprise side you'll get an Oracle system which is a little more hairy but in that, all your forms and reports are just little PL/SQL modules.

    Anybody who writes their own and cans it is in my not so humble opinion an idiot.

    Actually, we are moving from an older non-standard db to the industry standard. The version we are on is easily 15+ years old. lol

Comments are closed.