Peer to Peer Magazine

P E E R T O P E E R : I L T A ' S Q U A R T E R L Y M A G A Z I N E | S P R I N G 2 0 1 9 23 in and participation of the many busy systems professionals responsible for the operational systems that feed it. It is one thing to agree that having a central, high quality and easily accessible repository for key business data is a good thing, another entirely to commit time and resources to making it happen. Those who have the most knowledge of their individual systems are also the busiest. Nevertheless, I am happy to say we have made it work. We generally meet monthly to discuss new requests for data, the security and appropriate uses of existing data, and the logistics of incorporating new data into the ODS. Those meetings are also an opportunity to highlight the benefits of the ODS - not simply to the firm, but to those very same busy systems professionals. The benefits to these participants come in the form of fewer one-off requests for data, reduction in the propagation of "bad" data (i.e. that which may be misused or mislabeled), and knowledge transfer across systems groups. are still) discovering what types of analysis will prove most valuable to the firm. Of course, should we choose to implement a data warehouse at some future date our ODS will make that effort much easier. In addition to being a source for data analysis and reporting, an ODS can act as a "data hub". In the diagram above I have indicated this with an arrow feeding back from the ODS to our source systems. For example, when Active Directory (AD) needs user names, groups, and departments it can obtain them from the ODS rather than querying our Workday HRIS system directly. Similarly, when our Salesforce CRM system needs the client responsible attorney it can load it from the ODS rather than going directly to Aderant. By using the ODS as a data hub, fewer queries need to be written and maintained, resulting in less effort and more reliable data transfers between systems. In the beginning … Perhaps the hardest part of launching an ODS initiative was in obtaining buy- F I G U R E 1 : T H E R E L A T I O N S H I P B E T W E E N S O U R C E D A T A , O D S , A N D D A T A W A R E H O U S E Building a shared data vocabulary An important byproduct of these meetings is the knowledge transfer across the systems groups regarding the data stored in their respective systems. Even seemingly "core" data can have different meanings in different systems. For example, the definition of "industry" used by Marketing in the CRM system may differ from that used by Finance in the accounting system. Such differences in data meaning may exist for valid business reasons – or the respective systems groups may decide to bring their meanings into alignment. Either way, these discussions improve clarity across teams with respect to core data. Early in our journey we decided to create a data dictionary to track all data that had been proposed or incorporated into the ODS. This data dictionary is really just a place to store and find data about the data, and provides a great resource for those seeking to understand the structure, purpose, restrictions, and sources of each data element available through the ODS. Don't worry too much about the technolo used to implement your data dictionary. The important thing is that it should be easily accessible by all who need it. A simple SQL database + web application works great, as does a SharePoint list. Even Excel can be used, although it will be harder to ensure that only one "master" copy of the data dictionary exists in this case. A second benefit of an ODS is improved accuracy and consistency of data across the organization. This is not simply a matter of having the right number for billings or hours worked, but ensuring that everyone understands the meaning behind the data. Documenting the data in the ODS is necessary but not sufficient to ensure that all users have a consistent understanding of its meaning. Once a data dictionary is in place it must be promoted as the authoritative reference for that information. The most important target audiences for the data dictionary are application developers and

• Cover