In my last post, I talked about the debate between packaged maintenance software versus in-house development. Now I’d like to focus on how to choose the best solution for your organization. So let’s dive in and talk about what you need to think about when you are researching both options.
The People Who Use It Matter Most
Most in-house programs were created to meet a particular need for a particular group of people. What happens, however, is both the people and their needs change.
We’ve replaced a lot of custom, in-house software programs over the years, and I’ve seen the good, the bad, and the ugly. While many of these programs are fine in terms of their core functionally, usability is usually a problem. It takes time and money to develop an intuitive user interface for an in-house system, and most organizations focus solely on functionality.
Additionally, user documentation for in-house software is usually inadequate or completely absent. So even if a few users know how to use it well, many more feel like they can’t use it and can’t learn how.
Then either your IT person or your primary users leave. What’s left? Unused software that’s sitting on a desktop and can’t be updated. That’s wasted money and resources.
Software Programming is Specialized
There’s a misconception in the business community that if a software programmer or IT person is good at one thing, they will automatically have the skills to do anything else related to technology. The truth is, today’s IT people specialize. Maybe your IT team is great at networking or connectivity. Maybe they know database administration. But maintenance software programming is a different skill set.
Now I know a lot of very good software programmers. I’ve hired them too. So I understand why I need the right people who can grasp the nuances and complexity of today’s maintenance needs. Maintenance software programmers need to understand what maintenance personnel need today—and what they’ll need in the future.
It’s highly likely an internal IT team will take much longer to development an in-house system because of these different skill sets. Plus, this type of project takes them away from their other important tasks.
Our MPulse software developers don’t work on our networks. They don’t work on our accounting or billing processes. We don’t distract them from their most important task—meeting the needs of today’s maintenance teams.
Those are just a few things to think about. We’re not done yet. Next time, I’ll talk about how the maintenance field has changed, and what that means for your decision.