Delivering organisational change can be a tricky business. In order to adapt and grow, a company may need to tweak or change its organisational structure, processes and systems – and often, Information Technology (IT) is an important enabler for change. Of course, IT will only represent part of a change, but it can be an important catalyst and if implemented well, it could even enhance or create a competitive advantage.
In the rush to implement new IT or different IT, there is often a focus on the required functionality. People focus on what they want the system to do and the exciting new features that they’ll be able to use. In the excitement of building or buying a new system, data sometimes becomes the proverbial elephant in the room. Everyone knows that it’s important, yet somehow it gets pushed from the agenda. With the focus firmly on the visible functionality, there may be less appetite to discuss data.
Whilst this rush for quick implementation of functionality is understandable, when this pattern occurs, it’s really important to ask the question: Who is considering the data? There is a real danger if the answer is “nobody”.
Data dangers
After new IT applications are purchased and installed, they will be capturing, creating and processing organisational data. In large and mid-sized companies, there will almost certainly be integration or interfacing with other systems. If we’re really lucky, there might even be a data migration (and let’s face it, who doesn’t love a data migration project!). If we focus purely on the functionality, and do not place adequate focus on the data, there is a real danger that our data model and data structures will suffer.
In fact, I’m sure every single reader will have seen tangible examples of this. Whether you work for a small, midsized or multinational organisation, I’d guess that you’ve seen examples where there are multiple records representing the same customer over several systems—and they aren’t quite kept in sync. Or perhaps there is a billing system that doesn’t quite match up with a marketing database, meaning that we send discounts and offers to customers who constantly fail to pay their bills. These, along with many other similar examples, illustrate the importance of carefully analysing and considering our organisation’s data. It’s important to avoid haphazard changes that pollute our data or damage its structural integrity, or we risk finding ourselves in a situation where we can no longer get an accurate and holistic view of our business.
This becomes increasingly important when data is used to drive insight and decision making. When data is disparate, out of date and unreliable, a dilemma occurs. Managers and executives receive reports, but they can’t trust the data that is presented to them. They are seeing an outdated view of their business, and may be seeing only half of the picture. This can seriously inhibit decision making – and delaying decisions can make material differences. It might mean that you’re second to market rather than first.
Business Analysis and Data
Within the Business Analysis community, it’s time for us to debunk the myth that data is somehow “technical” and the myth that data only needs to be considered by developers or systems analysts. It’s often said that data is the lifeblood of an organisation, and we should find more opportunities to talk about the business data with our stakeholders.
After all, talking about data might be perceived by some as scary and painful in the short term. But the long-term consequences of ignoring it are surely terrifying.
How do you ensure that data is considered at the right times in your organisation? Do you have a related story or comment? I’d love to hear from you. Please feel free to add a comment below.
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for Midsize Business and opinions are my own. To read more on this topic, visit IBM’s Midsize Insider. Dedicated to providing businesses with expertise, solutions and tools that are specific to small and midsized companies, the Midsize Business program provides businesses with the materials and knowledge they need to become engines of a smarter planet.
‘it’s time for us to debunk the myth that data is somehow “technical” and the myth that data only needs to be considered by developers or systems analysts.’
I was just wondering what happened to the “logical data model” and the “business domain model” and all the other techniques we used to use in the past, a long time (2-3 years) ago?
Are they out of vogue? Discarded? I even used ELDs quite a lot – I know, SSADM, not agile stuff, but come on, one of the most useful tools. 🙂
Roland, I couldn’t agree with you more. I think logical data modelling is really important.
I don’t think they are discarded; I suppose that we’re more likely to see a Class Diagram than an ERD these days, and perhaps more likely to see a UML Finite State Machine than an Entity Lifecycle Diagram, but they are showing very similar information and relationships. Yet there is sometimes a view that the BA shouldn’t “do” data… and it’s that view that I suspect we both disagree with…
And hey, I think modelling is very Agile. After all, with an appropriate model we can concisely and precisely communicate a huge amount 🙂
I couldn’t agree more. One question though:
Consider a BA who is a part of a team that is building an enterprise application from scratch.While building the data model (using any method), how far and wide should that BA’s perspective be considering the current application and data landscape of that enterprise? I understand this a subjective question and it is an Enterprise Architect’s Holy Grail to achieve perfect cross app data integrity, but your perspective will be helpful.
What has been described in this article is what is going on within my organization. One customer may have more than one accounts in one system due to last name of after married. Not to mention data for the same customer in another system. We are currently exploring new suitable
system. One of the goals is to migrate clean data into new system. It is going to be challenging as time is tight.
Any ideas about cleaning data would be appreciated very much.