Today’s software systems are advancing faster than any other time in history. Each is going in different directions. The competition is not necessarily with the software company that creates and sells a specific software such as a calibration or quality management solution—the real differences are the platforms behind the scenes.
There is a war going on and it is presently being fought in the cloud and by cloud providers by both the main players like Google, Microsoft, and Amazon, and many others. Each development platform offers a different pricing and billing structure and a completely different backbone and approach to programming. So the software company wanting to build an app and offer it to their clients must first buy into one of these programming systems.
One of the most critical new requirements is the ability to synchronize data between the cloud and individual devices that are not always connected to the internet.
For example, software that was developed three or four years ago using ASP.net and MS SQL may be limited to features of new standards offered to programmers by Google or the latest AZURE. Often it is useful to understand the app’s server capabilities and the backbone to which the app was developed.
One of the most critical new requirements is the ability to synchronize data between the cloud and individual devices that are not always connected to the internet. For example, a technician using a tablet in the field performing inspections may not have access to the internet but would have the software app on the tablet and could enter the inspection results in the same manner as if the tablet were connected to the internet. Then, once the tablet connects to the internet, it would automatically synchronize the records and the inspection results would be available on the cloud to everyone.
Additionally, the app should be available on all platforms including tablets and phones from Apple, Android, and Windows.
This requirement ensures that management and users can work on their system using any device while connected or not connected to the internet.
When evaluating costs, consider the cost of full access—including future growth.
Glitz and Show
Software and graphics have also come a long way and often software apps are focused on glitz and show rather than complete functionality and integration. Beautiful graphs, charts, icons, colors, and layers all provide a tantalizing user interface. However, these features may limit certain software capabilities and more importantly, increase the costs of the software dramatically. Charting, reporting and glitz is often a third-party developer add-on to the app and is normally licenced to the software developer at huge costs, either by cost/customer or by yearly licensing fees which get passed on to the user.
There is a better way. Consider an app as a data source. Organizations may have multiple apps and may want to combine and analyze data from several of these. They may also want to incorporate other interesting data sources (such as weather). So instead of having these wonderful graphic programs in each app and paying for each of them, it may be better to own your own charting and graphing app that can interface with all your current and future apps including additional data.
Having your own charting app would enable the user to create charts from data pulled from multiple data sources such as the accounting software, local weather data, quality management software, and integrated robotic inspection software. Perhaps you want to create a graph comparing repair costs, hours labor, inspection rejects, additional production time, and weather for a process. Your own charting app would make this easier.
Therefore, it is more important that all apps can share data by providing you real-time access to the database data in the cloud. Often the app sends periodic downloads to a server IP, but the data may not be as current as real time access to the database.
Finally, when looking for an app, remember that what you see in the online demonstrations is well thought out data entered to provide beautiful graphs that appear to be very useful. However, we know that in the real world the data rarely lends itself to nice graphics and is often better analyzed in a spreadsheet where we can compare numbers.
When evaluating apps don’t be too influenced by glitz and stay focused on functionality and real-time access to the data. Look at your own processes and identify your specific needs, terminology, process flow and ensure that the app can meet your needs today and can grow and expand to meet your future needs. You should have the ability to completely customize the software to meet your present and future requirements.
The first chart is one of these well-planned data entries that demonstrate a beautiful chart and data range. But the repair costs may be far more than $200 and are more likely to be thousands of dollars. The graph would then look completely different as seen in the second chart, and a spreadsheet would be more useful.
Seats and Access to Customers and Suppliers
Seats or user access is a dinosaur from the eighties when bandwidth and storage was a premium. But today that simply isn’t the case. Why would an organization want to limit the user interface with an app that is supposed to help manage the organization? Would it not make sense in today’s environment where everyone has a certain level of computer experience that everyone in your organization may have a need to access your app for one reason or another?
Too few seats mean that a select few are burdened with data entry when the data entry could be performed at the process by the operators. Often the cost per seat is so expensive that organizations buy far fewer seats than they need and then play a game of ping pong back and forth between managers requiring access to their app.
Furthermore, suppliers and customers should have access to participate in your management or production systems with controlled and limited access. But if each are considered a seat and you have 1,000 customers, then the seat approach may be very expensive.
Software should be software and user access in most cases should be for everyone in the organization. One example is documentation and procedures. Why would it not be desirable to have the procedures and work instructions available online in the system to ALL employees?
A software that may have a few extra benefits but limits the seats may be less effective than a software missing a few features but allowing full access to all employees. Therefore, when evaluating costs, consider the cost of full access including future growth.
In conclusion, today’s software is becoming far more difficult for the consumer to evaluate. Today’s online demonstrations are designed to highlight the best that the software has to offer. Make sure you use that opportunity to determine how well the software meets your needs. Remember, once an organization buys into an app and pays the upfront fees, training, and implementation fees it becomes too late to reconsider the decision and they are forced to work with what they have.
Smaller organizations may want to hire an IT specialist to participate in the evaluation processes and provide simple explanations of the pros and cons of each evaluated app. Smoke and mirrors has never being so prevalent as it is today when it comes to evaluating expensive software apps to help manage your business.