Reflections – Data & The Human Factor: Awareness To The Hidden Risks

 In order to avoid being caught in the “religious” battle between business team and technical team, I have decided to pick a few scenarios and then use them as examples on, where I have seen the human factor put things to a risk before an awareness to the risk factor occurred.

There is more than security at stake

Business requirements represented in a “Sales budget” or the competitive “Time to marked” environment often forces the (lean) organization to be creative in order to fulfil the management directives. As long as there are no issues this is often handled by the management team as Lord Nelson under the Battle of Copenhagen 1801, but we are in a situation, where this kind of creativity put the business at a severe risk.

Risk factors – the human approach

As I wrote in my second article on LinkedIn (re-posted here at my blog) you have to see the company IT platform as an Iceberg.​

I have over the years seen many IT projects being challenged due to the habits of not investing time in securing, that both the stakeholders and their teams shared the same understanding of the requirements, the technical challenges and legal requirements.

 When facing a similar situation I have used this expression: “Draw your intended solution using pen and paper showing input, data handling and output – then we can see if is possible to build and implement”.

In some of my projects I have executed this exercise with a group of business and technical minded people with interesting results. One of which were the “wake-up call” as the participants realized the importance of having the same understanding of the data flow – especially where the raw data were initiated.

Generating business reports scenario

“Business Case”, “Sales budget”, “Customer Analysis”, “Product Analysis”, “Production Analysis” or “Forecast Scenarios” are often used in the communication with/ within the management teams.

Until Microsoft positioned their Excel product as the preferred tool by the business teams for generating financial reports, data were collected manually by the business team or by requesting IT to generate data extracts out of the business systems – which often took time aka hours if not days. This data extract were generated by a technician, who often happened to pick the data from the right tables, i.e. the right location in the data process.

Introducing the report functionality in the business systems lead to development of products that could use the data export from the business systems and then generate a huge variety of business reports. However, the first generations of these tools required a high level of technical understanding.

Microsoft paid attention to this potential and managed to define a standard interface for exporting/ importing data between Excel and various database products. This functionality made it easier for the business teams to use the “real” business data in their report work.

I have too often seen that the “power play” between business and technical teams ended up giving the business team a “full” access to all the tables without having executed a proper analysis of the source, i.e. whether a table represented initial input or processed data based on manual or system calculations.

The business report tools requires training

“A fool with a tool is still a fool”

The organization need to have an awareness of where data are initiated in the business process – there are no difference in relation to the use of correct data whether a “manual” process or an automated system generates the data and the business reports.

A tool like Excel do have a lot of build in functionality, like the capability to “semi-automate” the calculations. If the end-user happens to have little if no knowledge of how these functions operates, we have a high risk for errors.

No matter which tool a company are using for reporting, the company will need to secure, that the end-user are given a thorough training in how to use the features properly. I have experienced accountants with only a basic training using Excel for complex reporting to the management team seeing the consequences, when an error in the calculations just happened to be discovered after several months of use.

Pay attention to the data

Using just one business application reduces the complexity, however I recommend to pay attention in documenting the data used, i.e. where in the process are they taken. I have been working with applications, where it turned out that – in a 4-step process – the data in the tables happened not to be identical despite they had the same label/ field name.

Companies with an IT architecture where data are shared internally or externally between systems do have a higher risk for using the wrong data. With reference to my third article at LinkedIn I will strongly recommend that you prioritize to document the data flow using the TOGAF model and start using the ArchiMate standard for documentation.

As mentioned above then “full access” to the data can result in unpleasant situations; I have seen financial forecast been based on processed data rather the initial raw data captured. The outcome was a company that had to reduce their forecast of the expected revenue dramatically when entering Q4 of that financial year.

The legal matter when storing data

Another aspect is where customer data are stored and used. An average company have their customer data stored several places based on the function using the data, i.e. Sales, Service, Financial, Marketing and IT.

Unfortunately the IT budget is often seen as an expense rather than as a strategic asset, so there are often a gap between what the business teams want to have available and what they actually have available via the IT Platform. As a lot of services are available on-line for a low fee, some business teams are tempted to use these on-line services – especially if they are convinced it will help them in fulfilling their business targets.

With reference to the GDPR regulation, all companies will have to execute a sanity check with respect to existing legal regulations. Having undocumented solutions in use gives a potential risk for being in conflict with a regulation – especially when working in an international marked.

The quick fixes behaviour – business vs. technology

Introducing the personal computer to a marked price, where private people could afford it increased the end-user expectations within the business teams, that the business data – captured or processed – rapidly can be modified or made available.

Business requirements represented in a “Sales budget” or the competitive “Time to marked” environment were often used to force the IT department to be creative in order to support the business teams. This creativity had to be executed next to the daily operations, so the outcome turned out to be a lot of undocumented quick fixes or temporary solutions, that newer were completed. 

These solutions represent a potential risk for generating a red situation, when core systems are upgraded or replaced with a new “One Tool Platform”. I have experienced that issues in the newly implemented system turned out to be a non-documented fix in the interface handling inbound data between existing systems.

​Continuous improvement of the competences within the existing staff are more or less none-existing in many organizations. The solution has often been replacing existing or recruiting new staff members with competences in methodologies like SCRUM, competence within tools like Ruby on Rails and WordPress, not to mention competences within solutions based on Cloud services like AWS or Google.

In my first article at LinkedIn I mentioned the importance of having everything documented and not just relay on the knowledge within the employees. Having the approach of replacing staff members to fit the required skills rather than giving them the required training increases the risk for loosing knowledge about the real configuration of the IT platform.

In my second article at LinkedIn I addressed why securing the match between the Business Strategy, Business Processes, Data Processes and Legal requirements are critical. I just have to repeat myself on this – the company will waste a lot of money if this match turns out to be non-existing.

As I mentioned in my first article at LinkedIn companies will need to catch up on having the full overview of the match between the Business Strategy, Business Processes, Data Processes and Legal requirements. I recommend using the models mentioned in my third article at LinkedIn with an open mind – I do believe in it is better to use a reference model with identified holes than no reference model at all.

​STATEMENT: 

It is to be preferred that you document a topic by writing: “Subject identified and put on the list of actions to be completed at a later stage.”

Using this approach you at least document the awareness of the topic, by giving it a low priority.

Next in line

In my next post I intend to touch the “On-site vs. Cloud Design” scenario with respect to the factors, where the business needs to have some serious thoughts.

​This post was initially posted at LinkedIn on 18 August 2017.

Image Credits:

Thank you for having read this article – hope you have enjoyed it and that it has given you some ideas of where to start improving your own business or individual role.

Best wishes for the future.