Teleperformance Alert Management Framework
TPAlert is the framework and back-end behind my current (as of July 2010) project at work. The current front-end, called TATT2 (or "Tattoo", if you want) is under construction, and will represent almost as big a leap for TPAlert as it was in itself when I put the first version into production.
This is going to get boring and long-winded, but if you're truly interested in software I've written, I'm afraid it's a must-read...
Since the company owns all rights to the source code, I can't post any of it here, even though there are some parts I'm especially pleased with and would like to share. Oh well, such is life as a professional programmer, I guess!
Pre-history
A team at work, called The TCO Team, has been working with improving the customer experience for our biggest client for some time.
When they started calling customers to check up on units after repairs, and proactively informing customers of delays and hiccups repairs, there was an overwhelming response from the customers: They loved it!
Not only did the TCO team improve customer satisfaction, they also identified improvements that could be made to the service and replacement procedures of the client as well. Happiness and profit all around!
Of course, as any trial project, very little work was laid down before it was started. There was some "software" in place to handle the new procedures, but it wasn't much. I have no beef with Microsoft Excel, but I think it's being used for a lot of tasks it was never intended for, such as the TCO case database when they first started.
It was a several megabyte XLS monster that ate away hours and hours just in data imports, let alone the slow and cumbersome work processes that had to be followed to please the Excel Gods.
This is when my predecessor came into the picture. He was tasked to build a replacement for this Excel monster and deploy it as soon as possible.
I can tell from the code I inherited that he's an exceptionally bright person, as the logic is extremely good, but his inexperience showed very clearly.
- No input sanitation
- No separation between logic and layout
- No sense of security
- No optimization of database tables
- Very limited logging
- Very hard to extract usage statistics
- Horrible performance
Now, don't get me wrong, the software was fine considering it was the first PHP he had ever written, and I will for ever stand by that I think the logic is extremely good, but that is not enough for an actual workhorse application. For that to work, you need something a book about basic PHP can never give you: Experience.
I'm not saying I'm an all-knowing programming guru, far from it, but I've had several very successful hobby projects, and one of them ("The Great Machine" that I wrote as a companion to Vendetta Online) was similar in concept to what I needed to do for the company.
When the old PHP-based system started to come apart due to performance issues, and moving it to a new and more powerful server utterly failed, someone in the IT department came to me and asked me to look into it.
Of course I looked into it, and I got it running, sort of, but it was very clear that the application needed to be replaced.
Initial construction
First of all I needed to map out exactly what was wrong with the PHP-based system so I didn't make the same mistakes again.
Working with Kim, the Alert Manager, I mapped out the shortcomings of the existing system, and started work on a new one that would do the same thing, but better and faster. Since I was given absolute freedom as long as I delivered good software, I decided to go with my favorite language: Perl.
With the initial version running very well, I started moving tasks from the old system to the new one, piece by piece. It didn't take long before I had completely taken over all the tasks that I needed to take over, and with a salute and a tear-wet goodbye, the old system was pulled from production.
There it was, in all it's glory, my first Real Professional Software!
Actually, it was two pieces of software, since I had separated the framework (TPAlert) from the application (TATT, Teleperformance Alert Team Tool), but they were both useless without the other, so they are the same project.
Further development
Business needs shift, but what is constant is a need to keep tabs on what people do. In the company, the culture is not so much about identifying lazy people as it is find out what we can do to boost productivity, so I sat out to build a statistics engine that would do just that.
Within a relatively short time I could tell exactly what was giving people trouble in the application, and I could identify what needed to be done. The Alert Manager could see which of his agents that needed his assistance, and quickly identify when up-staffing was needed.
As the statistics engine grew it also became clear that we needed to measure agents in more detail, and to audit their work in the tool, so that the Alert Manager could identify training needs.
This was when Kim and I came up with The Auditing Module.
Quite simply, it puts an extra set of fields below the regular case view, where the Mentor/Auditor can see everything that has been going on in the case and score it based on internal and external requirements. In the end it comes down to a pass or a fail (usually pass, actually!) and the Auditor can give feedback to the agent in question. This is then printed, signed and archived.
With auditing, a simple news feature, and many other little pieces that improve communication between the Alert Manager and his agents, I feel my tool has done a great deal for the information flow in the team, and everything points to a large jump in productivity all around!
Times of change
Not long after I officially moved to Beta 1, meaning that the software was feature-finished and just needed a bit of polish before it was done, the business needs changed a whole lot.
Suddenly the software was getting a lot of attention, both from other sites within the company, and from the client it was originally built to work for. Two different projects, "CROSS" and "Platinum", are now battling for supremacy of the software, and I'm pretty much stuck in the middle with my head down while the bosses figure out the politics between them.
What has happened, of course, is that the software has gone from "Version 1 is almost complete" to "Version 2 should have been ready last month!"
This reminds me of the stories I've head from my friends in the software business, and I know it has to be like this. In fact, I love that it's hectic and that impossible deadlines are looming, as it hones my edge and forces my concentration.
I'd just wish they could leave me out of the politics, as I have exactly zero authority in the company...
Oh well, the rebuild of the framework (Still called TPAlert) and the tool that uses it (Now called TATT2, or "Tattoo") is coming along nicely, and while I don't think we'll get it done by the actual deadline it should be very close in deed!
The future
Once we've squared away "Platinum" and finished up "CROSS", and things start to settle down slightly, I'm going to review usability of the tool and catch up on the documentation that I haven't had any time to write. That, and of course, integrating with Active Directory and have the reporting engine export to native Excel files.
This is going to be fun!