This is the third in a 3-part guest blog series by Nitin Joshi, a Principal in SAP's Business Transformation Services consulting group. Nitin's series will focus on Overcoming Roadblocks to Enterprise Data Management. This final post tackles seeing data as more than a technical issue.
A business executive while presenting program approach to his team was talking about the need to think comprehensively in terms of People, Process and Technology. He was rightly proud of the fact that the program leadership team was thinking broadly in terms of people, process and technology. But when I asked him how he saw the Information or Data dimension being addressed in the program, his reply was “data would be part of technology”. It is no surprise that someone in business thinks about data as technical but I have known IT managers who also think that data is technical. This misconception leads to the roadblock that master data initiatives are perceived as implementations of MDM technology. It also leads to other challenges in the MDM project such as marginal business involvement. On some large initiatives such as ERP implementations or business transformation programs, an MDM project is added to solve the master data issues. When MDM projects are approached this way, they often lack a comprehensive approach of addressing the master data challenges along the dimensions of Data Governance, Data Architecture, Data Standards, Data Quality and Deployment. When MDM is perceived as a technical issue, the focus is more on solving IT issues such as data integration and data availability in systems. However without the stewardship of data in business, there is no one accountable to provide oversight to sustain the data quality on an ongoing basis.
Although data is stored in databases that are managed by IT, it is really the business of business organizations in your company. Data is needed to run your business processes and it needs to be converted to meaningful information so that executives can make informed decisions about running the company. Irrespective of whether processes are automated using technology or not, data is still needed to run the processes. If you take a hard look at what a process does, it receives data as the input, transforms it and produces data as the output. As a result data is closer to process and business than it is to technology. Application developers and database administrators might know more about database schemas, SQL queries and how to improve the performance of those queries, but they do not understand the business meaning behind that data. It is only the people in the business that can articulate how good quality data keeps the processes humming smoothly or how bad quality data can create inefficiencies in the process operations or result in poor tactical or strategic decisions or can even put the executives behind bars due to non-compliance and inaccurate reporting.
Best practice is to do conceptual and logical data design that collects “data requirements” at the same time as process requirements. While Business Analysts are gathering process requirements, logical data modelers or data architects could be gathering data requirements and documenting those in a logical data model. Data requirements and design are thus best addressed when they are done in parallel to process requirements and design.
How to overcome this roadblock?
Educate business and IT management on the role data and information plays in business operations, business decision making and compliance regulations. Data improvement projects will not be successful without strong and committed leadership from someone in the business. Business needs to realize and accept that they are the ultimate stewards of the data of the enterprise.
If you are part of the data team, you will need to step up your communication and use more business oriented language when talking to your business stakeholders. For example, speak less about database schemas, subject areas, entities and ER diagrams and talk more about how an incorrect address sends marketing material to the wrong place & wastes resources or how an incorrect or missing county in the customer address can result in over or underpayment of sales taxes.
About the author
Nitin Joshi is a Principal in SAP’s Business Transformation Services consulting group. He helps customers develop Information Strategy, Roadmap and Architecture with a focus on addressing business aspects of information management. Nitin has 18 years of IT and 15 years of SAP experience. He can be reached at his SAP email address – ni.joshi@sap.com.
2 Comments
