I am always intrigued by the way business analysts see things. Much like anthropologists and sociologists they get us to think about business culture and processes in a very different way. So I thought it would be useful to ask Jonathan Nituch of Fortress Technology Planners to talk to you about how words affect data integration. Jonathan is a part time Instructor at Sheridan College in Oakville where he teaches Analysis and Project Management. He is also a Project Management Professional, a Certified Business Analyst and fellow member of Silicon Halton.
Integration projects are all about communication. You are establishing communication between two or more systems. In order to get there, there is a different type of communication that you need to focus on: the communication between the business stakeholders and the implementation team who will do the technical work. We are talking about two highly skilled groups of professionals here. Unfortunately, they don’t always use the same terms or hear things the same way. Unchecked, these communication challenges can derail the entire project. Fortunately, there are some things that you can do as a business stakeholder to improve communications with the implementation team.
Get Your Terms Straight
It is amazing how much of what communicate is conveyed by context. Anthropologists study the tendency to use context in various cultures. Those cultures which use context extensively are call high-context. Other than your family, the highest-context group that you communicate with is your business peers. Your communications are filled with shortcuts, nicknames, and inside jokes. Consider the different names that individuals in your organization apply to the same thing. This variation in terms comes from a number of different sources:
- Terms used at employee’s previous workplaces. Once someone is using a term, they sometimes carry it with them throughout their career.
- Expressions found in your IT systems. If one of your systems calls something a Purchase Order and another calls it Replenishment Order, you can be sure that your staff will use both terms too.
- Word adopted from other parties. Your suppliers, partners and customers also have their own lexicon that your staff will appropriate.
- Terms from industry standards. Employees who have pursued education or certification may adopt the definitions used in those arenas.
Examples of Inconsistent Terms
What you end up with is a group of people who use different words for the same thing. Worse yet, they may use the same word to mean different things. I have never been involved with a project where I did not find this. In one case, the organization had two units of measure: inner case and master case. However, these terms were rarely used by the staff. They simply said “case”. Most of the time, the context of their message allowed the audience to understand which case they were talking about. Sometimes the context was lacking and the resulting quantities were vastly off the intended number.
Consider the word “customer”. Every six year old who has opened a lemonade stand knows what a customer is, don’t they? But, if you are a distribution company, who is your customer? Is it the ship-to location? The bill-to location? The head office that the bill-to is a member of? If the manufacturer is paying your commission, then are they not the customer? If you don’t have a clear definition of these words before you start you integration project, it will create issues.
Coming to Terms with IT Systems
Computers have no context. This is a black and white world where all communication must be clear and explicit. The use of inconsistent terms also affects the implementation team. Whether they are internal or external to your organization, the implementation team’s level of engagement with your group will be more intense during the project. As the team works to elicit your requirements, unclear terms can be a major impediment to their understanding. This delays the progress of the project and introduces the possibility of misunderstood requirements and ultimately flaws in the final product.
What You Can Do
There are some simple and effective techniques that you can use to help with these issues. The first is the use of a glossary. Create a shared glossary where your staff can agree on the terms that you will use. You can use the help file from one of your systems or and industry list as your starting point. I would recommend using a list of terms from a professional organization related to your field. Beyond helping your integration project, this will help get new employees up to speed if they are familiar with the standard terms. You can get your glossary in order long before your integration project even starts. When the implementation team arrives, your glossary gives them an excellent starting point for some documents that they may need to produce:
- Data Model: A representation of the structure of data in your databases.
- Semantic Layer: A mapping of the database elements to the common terms that your staff uses.
On one project, I gamefied the use of proper terms. I gave each employee ten tokens with Albert Einstein’s image on them. If an employee caught another employee using an incorrect term, they would shout “Albert!”. The offending employee had to surrender one token. At the end of the contest, the employee with the most tokens won a gift card. This got all of the employees thinking about their use of terms.
Some useful insights…our ebooks can provide more.