Lease Module
The first task on my plate was pushing out some new features in the Lease module. I began with reviewing their current processes and some ideas they had for improvement.
Bearing in mind that I know *nothing* about managing or reconciling or renewing leases. My FM experience has been in maintenance and engineering and only began to touch upon the space and occupancy management aspects a few times, when I became involved peripherally with the departments who handled our Medicare reimbursements.
Going from what I heard the Lease Manager and her staff discuss day to day, I examined the Processes available in WebCentral (a big reason for this upgrade was to get more users onto WebCentral and away from the desktop client, which we access via Citrix) with an eye toward removing unused entries and adding in new ones.
My consultant pointed out to me a new view that would eventually replace a totally custom view which my company had had built years ago. Rather than accessing data for leases in five or six different views, they were cobbled together and accessed through a single page. But, it was old technology and custom and didn't report in the LOG the way the standard forms did, when errors occurred. So, it had to go. With something closer to out-of-the-box, it would be more predictable, and would prove easier to upgrade the next time around. The new view would also provide direct access to the background data (buildings, cities, sites etc), which had only been accessible previously through yet more views, which many hadn't had been granted access to.
I relied heavily upon the Lease Manager at this point, explaining to me which data was most important to her team. The challenge to me, of course, was discovering which table each type of data resided in and how to display it.
The challenge being, not the display of data, but, the creation of new records. For example, I could get a building's address table to display the necessary fields with existing lease records, but, if I were to create a new lease record, it would fail because the address field was technically blank until said record was saved. The challenges of accessing a transactional system (SQL) with a dynamic interface (html).
There are "panels" within this new view, which each basically point to a different database, and are all coordinated by the lease code, the only data point common to each database table.
She may not have been able to articulate how the data interacted behind the scenes, but, that's not remotely expected nor important. Far more valuable to me were her explanations of why they needed each piece and how it was used. I learned an unbelievable amount about the process from the handful of informal meetings we had, hashing this out.
The system, as it was being used, was so customized in the older version, in order to provide features which did not technically exist within Archibus at the time, that it was a little difficult to rework existing data to fit into the newer structure (which does possess most of the desired capabilities).
I had to rely heavily upon our business partner at that time, to make changes and track down bugs.
This is really when I would've benefitted from that System Integrator class I mentioned previously. The interplay between the numerous SQL data tables, the Archibus AXVW's, and the supporting JavaScript files is rather complex, and I've no shame in admitting I was sorely unprepared for the challenge. I assisted our consultant whenever I could, but, did a lot of observing, too.
Now, as a nice, cold-bath-style introduction to being a dedicated SysAdmin, we had a sporadic bug with one of the panels. It kept breaking the view. For months we tried to track it down; most days it worked, some days it didn't. Each of us involved tried various modifications to the view, from top to bottom, but, the error would eventually crop up again.
One of my strengths, and what eventually led me abandon my desire to complete a degree in mechanical engineering and switch to computer science, is troubleshooting. I fiddle with stuff until I discover what is broken, and I find a solution to resolve it or a way to work around it. It's kinda what I do, no matter what software or hardware I'm supporting at the time.
It was unbelievably frustrating for everyone involved. None of the other customers using this same view had experienced anything like this.
Keeping the data logger on all the time, to try to record evidence of the problem, slowed the whole system down for users of any module.
We tried various browsers, my boss and I had IT ensure we all had the same version of js installed.
One suggestion that we never did try was to upgrade Tomcat, but, before doing that, we had the consultant's programmer recreate the offending panel from scratch, which finally worked.
It was then a challenge to get our very busy users back into the new form, when they'd gotten used to going back to the old one with which they were familiar, even with the other bugs it displayed (such as unexpectedly logging users out of the system).
I have been writing about CAFM/CMMS/IWMS systems for over a decade now, and one thing has always been clear... there is no out-of-the-box system in production.
We all start out with the same pieces, but, we tailor it constantly to fit our needs. This can mean a very challenging support environment and I can't speak highly enough of those who are capable of working so capably with it.
It's important to build a good rapport and mutual respect between users and supporters of systems. So, when those with the extensive knowledge of the data within the system notice aberrations, they are reporting them immediately and clearly, and the supporters can gauge how serious those issues are, and become familiar enough with the workflow, so that a minor bug doesn't become a work stoppage issue.
It was a wild ride for all involved, I'll admit. But, every person in our process was keen to work hard to put it behind us. You need multiple SME's here, use them all.
And let's ignore the costs for now, because neither customization nor support are free, nor should they be. As the technical rep for the client, it's up to me to balance requests and needs and implementations.
My time spent managing technology projects also long ago proved to me the importance of pre-planning projects, knowing what is and isn't covered in your estimate and contract is vital to budgeting.
To be continued... maintenance is up next, then space management, followed by data auditing and developing a roadmap of my own, after trying to bring to life the visions I'd been handed.
No comments:
Post a Comment