This article was written as an expansion of our white paper “Choosing Sustainability Management Software for your Business” published in July 2011. If you’re looking for information on how to make your software selection, check out the full article. If you just want to make sense of this particular topic, keep reading. Whether you like this article or not, we want to hear from YOU so that we can continue to provide the best insight for YOU, our readers…
Our series on Sustainability Software continues with “Data Management Concepts for Sustainability”. In this article (Part 3 of 4), we’ll continue introducing and defining key Data Management terms (read Part 2 here). Our end goal with this series is to enable YOU, as the Business Leader, to feel more comfortable in a technical discussion related to the various areas of Data Management, especially as related to the care and feeding of Sustainability Software packages. Being able to “talk the talk” is the best defense in the technology wilderness. Just remember, at the basis of any technical term is a common sense business notion, and staying grounded to this notion will help keep your conversations from drifting astray.
Data Movement is one of the silent cost areas of Data Management. This entails the replication of data into a system and then out of it on to another system. For example, suppose you have selected the ideal Sustainability Software offered in a SaaS-based contract by a reputable vendor. A qualified consultant is hired to mastermind the installation and the ideal algorithms are determined, tested and approved. All we need now is to move the company transaction data into it and let it do its work to produce the outputs we desire. What can be so hard about that?
Strong vendors of Sustainability Software will provide robust utilities to import data into their system and to export data from it. These must receive special attention from your Consultant and from your IT staff who will need to know how they work, at least for diagnostic scenarios.
We list some additional considerations below.
Suppose your consultant determines your current operational control systems can supply the data your new Sustainability Software needs and a prototype has proven this to everyone’s satisfaction. It seems like all we need to do is to rerun the prototype code every day and everything will work.
Axiom of Design: Everything needs to be designed at least three times: Once to see if we even really want what we had in mind, once more to learn how to build the ongoing system, and once more to really build what we imagined. Then Continuous Improvement kicks in.
You are in the process of building what is called a Data Movement Application. Any process that is repeated will fail often in new ways not anticipated. Yes, computers can break and humans make mistakes frequently, but tornadoes and blizzards happen too. We want repeating processes to repeat as planned, and this is why the first design of any software will be replaced. Moreover, you are probably required to prove to an auditor that all your data is being transmitted and received with very few errors that are themselves being analyzed and accounted for. This is motivation for an Automated Balance and Control system that manages your Data Movement and assures its accuracy and timeliness. If you intend all the work to be “outsourced”, be sure to consider these factors in your negotiations. At minimum, be prepared to self-ensure for these events—they will happen.
There are two main reasons to move data out of your Sustainability Software.
- To provide a report for approved readers
- To supply calculated data to another system
Reporting is technically “easy” now with all the Business Intelligence platforms that are available. Vendors include Microsoft, Oracle, IBM and many others. These tools are expensive but would be cost effective for SaaS providers because they can scale to serve many end users. They are being enhanced daily to also support information display on tablets and smart phones, so you can digest this information over the Internet from nearly any place in the world.
Data transfer to another system, however can be a different story. This will be a Data Movement Application and all the considerations we’ve raised above apply here as well, except your system is now the supplier of data and another system is the recipient. The complexities arise not only from engineering for repeatability, but from the likely need to translate source data so the target system can receive and interpret it appropriately.
(TO BE CONTINUED…)
Now that you’ve read this article, tell us what you think! And be sure to check out the full white paper.