Implementing a successful enterprise GIS

November 19th, 2018, Published in Articles: PositionIT

This article will detail a twelve-step plan to implement an enterprise GIS system, the key components to a successful implementation. It is based on the two-and-a-half-year process that Sasol Mining has undergone to digitise their spatial information, making the data more accessible to the general Sasol employee.

GIS is commonly thought of as a simple “geographic information system”, a system to manage and display spatial data. This could not be further from the true capability of GIS. In the past five years GIS functionality has expanded exponentially and managing spatial data is currently a small component of the full capability that newer GIS applications offer.

The focus within the GIS software industry has shifted to provide a more complete package offering seamless data integration, real-time spatial data analysis, complicated reporting, big data analysis and automation. Most importantly, accessing GIS data no longer requires a specialist skill set, years of software experience or a degree in geography. Users are now able to access vast amounts of spatial data through a web interface that is as simple as Google Maps. Furthermore, it is possible to provide the same end-users with the ability to perform complex spatial analysis within the very same web map environment. The capabilities of GIS software are expanding every year, moving further away from a specialist software towards decision makers and managers.

Sasol Mining has digitised its spatial information to make the data more accessible to the general Sasol employee. What follows is a twelve-step plan to implement an enterprise GIS system based on this experience. Fig. 1 shows an overview of the steps.

Fig. 1: The 12 steps to a successful enterprise GIS implementation.

Fig. 1: The 12 steps to a successful enterprise GIS implementation.

Phase 1: Base GIS deployment

Step 1: Understand enterprise GIS capabilities and limitations

Is a GIS platform the answer? To answer this requires a thorough understanding of what the software can offer. If your needs are spatial, then a GIS solution is most likely needed. While your local software service provider will be more than happy to demonstrate the high-level capabilities, functions and bells and whistles, they usually do not fully understand your requirements and business. Instead, visit a similar operation that has an operational enterprise GIS system and can show you the practicality of the implementation, and how it does or does not enable users.

It is important to define the minimum requirements of the GIS end users, i.e. the most necessary deliverables of the software to solve the problem. This could be 24/7 availability of spatial information via a web map interface; spatial data capture on mobile devices and seamless upload; spatial reporting; an integrated digital map that works with other systems; complex spatial and statistical analysis; or process automation and integration to help optimise business.

Once you defined your needs, understand the functionality available in enterprise GIS and assess whether it meets your requirements. Research, discussions, demonstrations and conferences are the only way to determine the answer to this question. There are also countless online resources to help build your knowledge of GIS solutions.

Step 2: Map your current business processes

The reason for mapping the business process to understand the data used and the flow of this data. Most business processes involve multiple departments, and it is therefore crucial to involve all role players when capturing the business process. This step forms the basis for a business case, and the information collected at this stage will be used throughout the design and implementation phase.

Sasol Mining mapped 60 business processes across seven departments in order to get a full understanding of data, users, documents and reports, and compliance. These processes stretched from the application of a new prospecting right through to the application for mine closure.

Fig. 2: An example of business process mapping.

Fig. 2: An example of business process mapping.

Focus on four elements:

  • Users
  • Data
  • Documents/reports
  • Compliance

Users: How many users are involved in the business process, and is this business process repeated across multiple locations?

Data: What data is used? Who captures new data and how? Where is the data stored, where is it used? What is the flow of data? Who is responsible for the data? Capture the frequency of the data activities (hourly, daily, weekly, monthly).

Documents and reports: What documents are involved? What data generates reports, where is it stored and how is it shared? What is the frequency of reporting and document generation?

Compliance: What KPIs are involved? Are there legal compliance activities? If so, where are these currently managed?

Step 3: Identify your data requirements

One of the strengths of a GIS system is the ability to store attribute data within a feature class, which can be used to distinguish or identify that specific spatial entity. For example, a pipeline may have an attribute to describe the diameter of the pipe and another attribute to describe the material being transported (water, waste, gas). Using the information from the business process mapping exercise it is possible to create a framework for your data structure. In order to build a solid data framework, you might need to collect examples of the data as a guide. At this stage it is important to structure your data in such a way that it will be able to meet the business process requirements in the future. Sasol Mining identified 108 unique feature classes with 653 attributes across the features.

In creating a data framework, identify the feature classes. This is comparable to levels in a CAD environment, where each feature class would represent a specific group of entities (buildings, roads, pipelines, shafts).

Then, distinguish attribute data for each feature class. For example, in a CAD system the colours and style of a line would indicate what the purpose of that line is. In GIS, this would be represented in the attribute table as columns, and within this it would describe the purpose of the feature entity.

Next, look at additional data requirements, such as logging the date and time and user that last edited a feature entity; or the status of the feature entity (e.g. planned or actual). Consider recording historical snapshots of the data.

Non-spatial data, which from experience comprises most of the data used to create reports, may have a link to a spatial feature. For example, the Excel report on tonnage per section per shift can be linked to a location since the section is spatial. Creating this link will enable the user to click on the section on a map and see the latest tonnage report. Other documents should also be considered, for example legal document associated with a farm or mining right can be accessed through a web map if the documents are linked.

Fig. 3: An example of a data framework.

Fig. 3: An example of a data framework.

Avoid data duplication. It is important to identify which of the required data you will integrate to the source system and which data will need to be stored in the GIS environment. Build a high-level diagram to show the key integration points (acQuire, Minex, Xpac, SAP, SharePoint, LiveLink, Microstation, AutoCAD) and what data will be flowing where.

Step 3 will be highly iterative as you collect and prepare data. It is therefore important to keep a record of this base data requirements to ensure that you can meet the later business improvement requirements in phase two.

At this point there is enough information to start the design for the hardware requirements for the enterprise GIS deployment. It is highly recommended that a specialist (or a registered software service provider) be involved in this process.

Step 4: Standardise and centralise your data

This step involves the collection, clean-up and standardisation of your spatial data across a single site or multiple sites. Depending on the scope, this can take very long to complete, and will cause changes to the data framework (step 3) as you progress.

The most important aspect of standardising your data is to ensure that there are mechanisms in place to maintain the implemented standards. Most GIS applications have many methods to maintain both attribute (domain, subtypes, XFM) and spatial data (topology) standards. It is important to implement these when cleaning and preparing the data for deployment.

The definition of data standards should include symbology (aligned to government requirements), naming conventions, layer groupings, the data maintenance process, the data quality review process, coordinate systems, and database structure.

Once the data is prepared it should be stored in a central location within a database (SQL, Oracle, etc). This allows for efficient data maintenance, troubleshooting, integration and backup.

Keep the owner of the data closely involved during this process to ensure that all requirements are met. This will also help with the later change management process. Enforcing the standards is only possible if there is a system that is able to do this, and it is a requirement (not optional) to enforce the standards.

Step 5: Integrate GIS and source systems

There are most likely established software packages used within the company, and there may be multiple packages fulfilling a similar role. At this point you have decided either to migrate to a new GIS package, or to integrate to the existing packages and data.

At Sasol Mining we decided that we would integrate the existing packages into ArcGIS Enterprise, and use the GIS platform to share data via web applications, run any spatial data analysis and improve business processes. Currently, 90% of the GIS data is created (to the standards that the GIS team implemented) in other applications. The remaining 10% is data generated in GIS, and is static data such as aerial imagery. This approach increases the complexity of the integration, but dramatically decreases the change management and migration/learning of new software.

The success of the enterprise GIS implementation dependents on the quality of the integration to source systems. The integration must be automatic (no user action), seamless (simple) and instantaneous (immediately available) from the source system to GIS.

Duplicating data should be avoided as far as possible. The data should ideally exist in a structured database in order to enable instantaneous integration. Integration is possible without this being the case, but there are bound to be errors during the integration process.

Fig. 4: The three fundamental integration routes.

Fig. 4: The three fundamental integration routes.

There are three fundamental integration routes, each with limitations and varying degrees of complexity:

  • Web–to-web: Integration of an existing web service into the GIS web platform.
    • Pros: Very easy to achieve, highly stable, automatic, seamless, instantaneous.
    • Cons: Limited configuration (rarely able to modify the underlying structure of the data)
    • Skills: Requires a basic knowledge of REST API, JSON, HTML and in some cases JavaScript for data manipulation from the source system (in most cases these skills may not be required).
  • Database-to-database: Integrating an existing database into a GIS database/web service.
    • Pros: Automatic, seamless, instantaneous, highly configurable.
    • Cons: Data access can be difficult (depending on company policies)
    • Skills: Query layers, database scripting (SQL, Oracle)
  • Extract, Transform and Load (ETL): Integration from non-database data into GIS (Excel, some CAD applications).
    • Pros: Highly configurable, highly flexible, sometimes the only alternative, many tools available.
    • Cons: Not instantaneous (usually automated to run nightly or monthly), highly dependent on the quality/standard of the input data, involves data duplication, unstable, could require user intervention to confirm a successful ETL.
    • Skills: Python, ETL tools (FME, Data Interoperability), VBA and many more depending on the source data.

There are also a variety of third-party applications to integrate from a source system and populate the data into a database structure. These should also be considered to ensure a more stable integrated system.

Step 6: Deploy the first phase web maps

Finally, the project is at the point where the GIS can add value by displaying the fundamental spatial data through a web interface. The purpose of web maps is to provide quick access to data from multiple source systems. The viewers need very little training to open the maps and navigate through the layers. The web maps allow more users to see more data without the need to contact the data owner each time there is an update. Furthermore, the feature entities on the map contain attribute data, which allows them (already at this stage) to filter data based on the attributes and run some simple analysis to gain deeper insights into the data.

The maps must be easily accessible and should be available to the users within three to five clicks from their desktop environment. The interface must be intuitive, easy to understand and navigate. It is important to track the use of the system per a user to refine your training and change management strategies. Some users require more motivation and/or training to fully embrace the system than others, and it may take time for users to gain confidence in the system.

At Sasol Mining we had two to three roadshows at each mine (six mines, ±40 users per mine) starting with upper management and then to the foreman level. Our greatest success (fastest user uptake) was the mine where the upper management told us not to come and present or train the middle management and foreman workers, as they would take on that responsibility. To this day, the users at that mine are still the most active.

Phase 2: Business improvement

Step 7: Design the future business around improved processes

The design of the future business process using GIS and workflow functionality should primarily aim to improve and automate data flow between systems, from the original source data (database, manual entry) to the final reporting. Upon investigation it is possible to see multiple overlapping workflows for each business activity. One example of this might be a complaints process: multiple activities within a department may result in a complaint from a third party. This complaints workflow should be designed as a module which can be placed within other workflows. This is an important concept as it allows for tracking complaints stemming from multiple business processes, in one database.

Modularise your business processes from the outset of the design. This requires a thorough understanding of all processes before building the workflows. Digitise the data flow by automating data transfer from multiple sources. This is the removal of the “copy and paste” exercise to generate different reports, as well as the mitigation of human error.

The implementation of the workflow should consider:

  • Flexibility: options for re-route, cancellation, postponement, escalation.
  • Visibility: the entire process needs to be visible in a workflow chart.
  • Trackability: the relevant users and stakeholders need to see the status of the workflow.
  • Accessibility: users should have a central location to access all workflow items.
  • Ease of use

Initially there may be business processes that do not require workflows in order to add value to the business. These might include spatial analysis tools, visibility of additional spatial data, live reporting, data migration (Excel to database) and data integration.

The Phase 1 data only included the base spatial data with limited attribute data. In Phase 2 the goal is to expand this data to meet the specific needs of a department or specific business process. An example of this is the farm boundary layer. In phase 1, this feature class only had the basic information such as farm name and portion number, which is enough to uniquely identify each polygon. In phase two, the contact details were migrated from Excel and then integrated to the farm portion spatial data. This requires no complex workflows, only to integrate data sources.

Step 8: Define data manipulation standards

There are a few key principles for data manipulation that are important to maintain in the second phase of implementation. The first is that the base data (input data structure) should not change due to the business improvement process, unless absolutely required. This is to ensure minimal interruptions to the data capture process. Secondly, in order to manipulate data you should consider query layers (SQL views) to join and alter data for reporting and alternate display purposes. Query layers in GIS are very useful to create additional value to the base data. They can help to avoid breaking the link between the base data and the reporting and analytical data. Ensure that the spatial data can be uniquely identified in the base data structure. This will prevent reworking the base data structure. This is required for features that need to be integrated with other data sources.

Fig. 5: An example of data manipulation standards.

Fig. 5: An example of standardised data manipulation.

Step 9: Define manual data capture standards

If at all possible, it is best to avoid manual data capturing and rather attempt to acquire data automatically. However, this is usually a longer-term plan and in the interim a system may require manual data capture. This data should be capture directly into a database with data quality control measures in place.

Create a central repository (database) to store data captured manually. There are multiple solutions available to capture data, however it is important to ensure that the solution is flexible and meets your requirements. From my experience a combination of solutions such as SharePoint, K2 and Survey123 may be required to capture manual data. Survey123 can be used to capture data in offline environments on a tablet or phone. SharePoint for list type data, similar to Excel table formatted data. Lastly, K2 could be used to capture data as part of a workflow or as form-type data capturing with multiple rules.

Step 10: Automate reporting

The majority of business processes result in a report or analysis which is used to make decisions. It is important to follow the data manipulation rules and create a data view (or query layer) for each report. This will allow for changes to both the report structure and the base data without breaking the link between the data and the report.

There is great value in continuous data flow into the system and automatically processed reports. This allows a standard weekly report to be converted into “triggered reports”, for example an exception report which only notify the relevant people if there is a problem. This avoids delayed responses, since the notification can immediately be triggered by any problem.

Microsoft SQL Server has built-in reporting services (SSRS) that can be leveraged with your database to create online reports. It is recommended to centralise the reporting data (views, query layers) into a single database to simplify management and user access of the reports.

Fig. 6: There is great valuable in continuous data flow and automated reporting.

Fig. 6: There is great value in continuous data flow and automated reporting.

When setting out on the automation route, re-think the reporting by determining if a report is adding value, or whether it is only the exceptions that add value. If it is only the exceptions, then focus on reporting only these. Email notifications should be limited to exception reporting or the bare minimum. Reports will become ignored if they continuously display the same data and show that there are no issues. Rather invest time to train the users to navigate the site to view the latest information when they need that information to make decisions.

There are often multiple levels of reporting on the same data. Therefore, build a modular report where some components can be reused for a different audience. The reporting is often the final step within a business process, and all the data collected is usually required for a component in the report. Each business unit/department needs to have some degree of flexibility to manage their own reports, especially when exception triggers and conditions are set. Make these flexible by storing them in a database where the administrating users have access to change this.

Step 11: User acceptance testing and roll-out

To improve a business process requires involvement of the primary users in that business process from the design phase onwards. When this is the case, it should be possible to complete at least 80% of the design before reaching the user acceptance testing (UAT) step. If the core team for the development and improvement of the business process was correctly selected, then this step will be less rework and more of a change management exercise.

Remember to stick to the scope of the business process. When completing the UAT and/or roll-out it is more than likely that the wider audience will have multiple new requests. Managing these requests and concerns is crucial. If requests are not met then the user feels undervalued, and if concerns are not addressed then the user won’t trust the system. Avoid ending in an endless loop of new functionality during the UAT and roll-out. Rather note these and address them in an update in the future.

I have found that once a report is automated that users immediately see the value. Before this point the process of improving the business has added to their workload and not reduced it. Automated reports and notifications are one of the easier components to sell as a value adding opportunity to a general audience.

Step 12: Advanced analytics and tools

The automatic reports are often not sufficient for most users to analyse data and investigate underlying issues. Therefore, creating data views for analysis might be necessary for business processes or projects. ArcGIS offers tools such as Insights and GeoAnalytics for analysis that focus more on spatial analysis. There are also multiple other tools available (PowerBI, Matlab, R and Tableau) to allow users to create these views in order to manipulate data.

What makes a successful enterprise GIS implementation?

Three main things make an enterprise GIS implementation successful for its users:

  • Ease of access
  • Effective GIS support
  • Business activity ownership

Ease of access

Within three to five clicks the user should have access to all the maps, documents, data, tools and reports. It is important to spend time designing the perfect gateway to this information. It must be intuitive and standardised across the entire organisation. Using the company’s intranet structure is usually a good starting point.

Effective GIS support team

Service providers and consultants are great to help get the enterprise GIS system started and to develop complex solutions for the business activities. However, to make the GIS system successful in-house expertise is required. An individual or group of people should have the knowledge to manage the GIS system, especially the integration points. If there is an issue with the integration the whole system falls flat, and quick repair time is important. The in-house GIS experts should manage and work with the consultants from the start in order to take ownership of the solution once deployed. This is critical to a successful system.

Business activity ownership

Do not take a top-down approach to develop and deploy an improved business process, because once deployed the GIS team should hand over the solution to the business units. Therefore, it is extremely important to have the business units involved throughout the process of design, development and deployment. This is not an easy exercise, primarily because in the beginning stages it requires the business unit to do additional work on top of their current workload. The time saving only occurs once the switch to the new system has happened. This is usually only towards the end of the project. The users generally only start to see the benefit once 80% to 85% of the project is complete. Up until that point it is difficult to convince them that the solution is beneficial. The first three to four projects require the most change management, but after that those initial users spread confidence in the solution.

Ultimately, a successful project depends on how involved the people influenced by the project have been during the design and implementation. The business users must have enough confidence in the system to take ownership of the solution and process. There are other factors such as stability, recovery, speed, data reliability and functionality that impact the success of the solution, however these are easy to manage with hardware and technology. Focus on the people and their requirements, and your enterprise GIS system will be successful.

Contact Chris McLean, Sasol Mining, chris.mclean@sasol.com