Recently I took a data warehousing class, and one of the themes was Data Governance, which is vital to design an information system. Until then, I didn’t pay a lot of attention to the term; I have worked with data all my professional life, so it comes naturally for me to organize, classify, process and give results. However, standardizing the process helps everybody get the best results in the shortest amount of time, and explaining this concept with the right words to the stakeholders helps empower any project implementation. After the class, I reflected on my experience, and here is the result of these insights. I worked as an ERP (Enterprise Resource Planning)consultant for many years, and I worked for several companies spread through Central America. Data Governance was the first activity to be executed after planning a project. When you are implementing an ERP or new technology at any company, the first question is what information will be needed to present results. The second would be how we will prepare and log the data into the systems to get the expected results. As with almost everything that has to do with systems, several organizations explain these matters to us, and a good one is the Data Governance Institute which gives us the following definition:
Data Governance is a system of decision rights and accountabilities for information-related processes, executed according to agreed-upon models, which describe who can take what actions with what information and when, under what circumstances, using what methods.
However, it is easier to say it than to make it happen. Throughout the years, I found that configuring a sound information system has more to do with getting to know the company’s operations and working with a team that possesses a thorough knowledge of their areas than the software per se. However, an external consultant will not do the job; the people executing the everyday operations with guidance will do the task at hand. Working in Central America allowed me to see how companies worked and performed their transactions in different settings. Because each country in Central America is small, the companies are not humongous. However, they have the complexity of any big company in a smaller setting. It is like working in your lab. I learned in this lab that getting to know the type of organization is the first step to organize the information. But you don’t have to learn from scratch. There is much documentation available on how a company is organized. A company can be a factory, a distribution company, a retailer, and so on. However, no matter what the company does, three factors influence implementing useful system information and a sound governance data system. These factors are the company’s depth, the breadth of the company, and the onboarding process.
The depth of the company refers to the diversity of operations that a company or corporation addresses. A company in the business of food, vegetables to be more specific, can have its farms to cultivate the produce. Then, the company may have its trucks to transport the produce and its stores to sell it, and also they can export the produce to other countries. The variety of operations could be wide. Each operation unit should be addressed independently so that every bit of information will converge into one information system that will provide results to different stakeholders. The depth of the company will determine the complexity of the data model.
Then comes the breadth of the company: how many branches does it have? Let’s say that the stores are located in three different states, and part of the exports to other countries are also sold in stores that belong to the company. The breadth can be extensive, and the information system should reflect the challenges that the company faces with these types of operations. Taxes can be different in different states, and of course, they are different in other countries. There are laws about which products should be sold in the countries. For example, you cannot send products manufactured using parts from countries that do not comply with international commerce agreements. When a company exports goods, there are rules to be followed. For instance, the company needs to send a certificate of origin that ensures that the laws comply. For me, the company’s breadth means paying special attention to the details because the law gets in the way, and an error in how the information is registered can lead to humongous penalties.
Lastly, the onboarding process refers to how the recording of all the data should be done. Each case needs to be documented, explained, and understood for each person involved in each process. The onboarding is a two-way highway because it suits informing and gathering information to update the process. Any information system is alive and changes. New products can come along with different types of operations related to them. New laws can emerge, and others may be eliminated. A company hired me to separate one of the units in the information system, legally they would be two separate entities, but the board needed the information to be shown as one entity. Some years later, this company hired me again to put together the companies in the information system. Everything moves and evolves and needs the means to grow and maintain like a living entity; here is where a sound Data Governance system helps keep things going smooth.
Like I said before, it is easier to say it than do it, so I would like to get into some detail about depth, bread, and onboarding by addressing each factor with real-life cases.
Depth
One of my most memorable projects started with a financial report on one page. This report’s sole purpose was to present earnings by-product and the expenses by each cost unit, the product could be a whole company, and the unit cost could be an entire factory. The board oversaw an entire vertical operation that included factories, distribution systems, and finally, a chain of restaurants in Central America that sold different menus types during the day. The verbalization of the requirement was kind of simple: “We just want to know the overall gains of the corporation in this report that we review each 10th of the month.” My mind was racing at this time. As a subject matter expert on the ERP software, my job would be implemented to achieve this goal. My first thinking was on creating the codification for the different operations in different companies and departments. Like everything big, first, you have to work with a team, and second, you divide the problem into smaller parts. The company made some sagacious decisions before they even start shopping around for software. One of these decisions was to choose a team of executives that had a thorough knowledge of the company. The people that they selected were the Chief Information Officer and the Financial Comptroller. Even though they already knew the company, they lacked some knowledge about the finest details in the operations, so they were separated from their daily activities and embarked on a one-year quest to get to know every company’s process at its smallest detail. They even made some trips as copilots in the trucks that made the deliveries to the restaurants. That reminded me of a question that one of my first bosses used to ask me: “Did you see it with your eyes?” and then he always finalized with: “You cannot create software for processes that you don’t know how to execute; without a computer.”
After they finalized their quest, they led a team that would include the main stakeholders in the different operations, and together they choose the software to be implemented. At this stage, I came along with the software. I became part of the team. We spent four months in a conference room designing the information system, basically all the codification that was going to be used throughout the corporation to comply with the legal and financial issues and present the one-page report. After two years, we finalized the project, and the most valuable lesson that I learned here was that a thorough understanding of the operation is essential. This understanding comes from the people in the company, not from outsiders. An external consultant’s job is to organize, moderate, and create an environment for positive outcomes.
Breadth
To exemplify a corporation’s breadth, I will cite the implementation of an accounting system for a regional bank. The depth of the project wasn’t profound since it only included financial products and service units. However, the breadth was extensive. The bank extended its operations from Guatemala to Panama. In each country, they had several branches. Here, the challenge was to address all the legal issues associated with each bank in each country, with different currencies in each one, while still maintaining the information system to inform the board of directors in Guatemala’s corporate offices. The bank comprised six countries with four different currencies in an unstable political environment. The government highly controls the bank system in Central America. There are many rules that each bank has to follow. The banks have to follow a codification that is standard for all the banks in the country. This codification aims to report operations like balance sheets, cash flow, and others into an audit system in the Central Bank. Then, a series of tasks are performed in the Central Bank, which includes, amongst others, auditing of the information and quota calculations. The banks have to follow many rules. For example, a bank has to maintain a certain amount of cash; a percentage of the savings has to be transferred into the Central Bank to protect the clients’ assets; the banks are not allowed to invest in risky operations. Indeed, there is a lot of control, which makes the lending of money highly expensive for Central Americans. Panama is the exception, and the Central Bank has a more libertarian approach to put it in some way.
To sum up, it was a very complicated situation because every rule, every asset, every operation must be reflected in the accounting system as the Central Bank commands. If the bank is local, it is not that big of a problem because the operations are reported to the board of directors using this arrangement. Still, when working with a regional bank, the operation’s codification becomes a big challenge, but not impossible. We found out that using and an intermediate codification would do the job, and of course, the conversion of all the operations to a single currency, which is usually the US dollar. The fixed assets are a huge problem because a bank has valuable assets, assets like building offices, and these assets are usually collected as payment for a defaulting loan. There are special rules that must be followed to convert these assets. An asset may have a different value when it was registered for the first time than when reported to the board, which means that reevaluation should be made. The big question here was, how do we organize six teams, in six countries, with six different legal scenarios? Again the answer continued to be the same; first, you work with a team within the company; then, you divide the problem into small pieces to be solved one at a time. In this case, we had a meeting with the financial comptrollers of each bank. We agreed upon an intermediate codification, and finally, we divided the implementation by country.
We started with one country, and once we proved our codification and processes, we continued with the rest of the countries. From this experience, I learned that stringent laws constrain creativity in the creation of processes. The implementation was lengthy, and it took several consultants to finalize it because the rules changed from country to country. We had a baseline, but a local application had to adapt the systems to each Central Bank’s requirements. The company’s breadth may add a considerable amount of complexity, so it is important not to underestimate the challenges of a horizontal operation that spans different scenarios. The challenges are not only legal or process-related but also culturally. The way people communicate, act and behave changes from country to country, even if they speak the same language.
Onboarding
No matter how much work you do to accomplish the perfect information system; or how well you devise the perfect report, if there is not a process to manage the communication of the rules of engagement to all the stakeholders, then the work done to design the information system is a waste of time. The project that showed me how data governance should be handle was the longest project that I have managed so far. Now I see it as one, but in truth, they were two different projects, and that is the beauty of the experience. In the end, I realized that it was only one project that lasted more than three years, which I called in my diary, the blue book project.
In most of the projects that I worked for, part of the job was the design of codification for each operation in a company: the bill of accounts, the products in inventory, the codification of the different departments in the company, and so on. The goal was to create a system of information that could later be easily translated to a data warehouse for business analysis, and at the same time to be able to integrate any summary of information and be able to audit the numbers presented to the board for accuracy. I do like patterns and order, so that job suit me very well. But it came the time when I went to a small company in Guatemala, which was a branch of a Salvadorean corporation. This company only had 15 employees at the most, which were the administrative and warehouse personnel. This brand’s purpose was to distribute a product made in El Salvador to the different supermarkets in Guatemala. The operation seemed very simple, which it was. But when I came to talk with the financial comptroller, he showed me a blue book and told me: “What we need is to for you to help us configure the system to comply with these sets of codification and processes.” The blue book described the codification of the products, the warehouses, the operation of a distribution branch, and the format of the reporting needed to present to the different stakeholders. The blue book also gave rules on how to adapt the codification so each branch could comply with the country’s laws. That indeed was an easy project. I went in and out in a very short time.
I also went to a matrix corporation in El Salvador. The company had the distribution operation plus a factory that manufactured the product to be sold in Central America and Mexico. The CEO of the company was Mexican. When I went to elicit the company’s requirements, they showed me the blue book again, and the request was similar, “we need to implement this codification and these reports to our main matrix company in Mexico.” But this time, it included all the operations of the factory, plus processes related to exporting goods to several countries. Again, my job was to show them how to implement the codification and create the reports to help them do the job. The implementation took me to the branch of this corporation in Costa Rica. Even though it was a little more complicated than Guatemala’s operation, the methods and codification were the same, all guided by the blue book; the only issue that I had to pay special attention to was the country’s legal requirements.
One year passed, and then the software was sold to a sister company of this corporation in Panama, so I went with the software. There I found was a distribution branch of a different type of product manufactured in several factories in Asia. This distribution company sold the products to all Central America, Caribe, and some Miami and Colombia stores. Again I went to elicit the CEO’s requirements, and he opened a drawer in his desk and showed me again the blue book. Well, I reread the blue book, but this time, only the sections that corresponded to the products sold in this branch, plus all the requirements to comply with exporting of goods. Panama is a particular country; the legal system is more relaxed than any other country in the region because of the Panama Canal. Many companies have distribution units there to take advantage of the fiscal incentives. The banks are relaxed and very protective of their client’s information, so it is a perfect place to do business. Again, I had to learn about the legal requirements and implement the blue book. The CEO was a temporary CEO. He was what they called an international executive, and his job was to open companies on behalf of this vast European corporation with operations worldwide. He had worked in Latin America extensively and received periodic training in Europe. He stayed just a few years in each country. He explained all the operations of the company and the purpose of the information systems, which was also described in the blue book. For me, this was one of the most rewarding experiences. It helped me realize how important it is the documentation and the preparation of people to implement a sound Data Governance system. We do not need a blue book, several software products accomplish this purpose, but the software does not make magic. The people in a team, discipline, and a thorough understanding of the necessities of a company are the elements that, when managed well, will create this magic.
I have worked in many companies as an external consultant. From this pool of experiences, I can say that these three examples are the ones that helped me the most to understand the purpose of an information system and the difficulties in implementing it. However, the challenges can be overcome by forming a team with the most knowledgeable people that the company has, a good moderator, and the understanding of the company’s depth and breadth along with the complexities that these factors add to the process of implementing a sound Data Governance System. Finally, the last lesson that I learned was that well-documented processes and data structures can ease the challenges of implementing any technology project by dictating a baseline to follow and still have room for improvement. To sum up, when you start a new project that has to do data, start by learning this information’s scope. The important elements that will help you with this task are understanding the operations’ breadth, how horizontal the organization is, and the depth of the operations, or how vertical the organization is. Once you understand your data and your organization, you can implement a Data Governance system. You can’t manage something that you don’t understand, thus, first, acquire the knowledge, and then you start governing the rules of engagement of this information.