Gord Cross | Principal, GKC Data Solutions

From a business conversation to working software.

I work with the people who know the business, understand the problem with them, and carry that understanding into the software.

That can mean mapping a process with operations or finance, tracing a rule through a SQL database, or writing the code that connects two applications. Moving between those parts of the work is central to how I approach a project.

Often the starting point is simply that something needs to change. I look at the process and assess existing software before recommending a way forward. If an application on the market meets the need, I recommend buying it.

My work includes systems integration, ERP migration, email filing workflows and document discovery. I help owners and finance leaders in professional services firms serving the resource industries carry business decisions through to working systems.

View services View projects

Inside an enterprise ERP

For about seven years I was Allnorth’s Continuous Improvement Lead, working across the project management office, finance, payroll, HR and the field. I led the UKG payroll implementation and integrated it with BST10 so information could move between the systems without being retyped. I worked through the business rules with the people responsible for applying them.

The work centred on project accounting: work in progress, revenue recognition, budgets, commitments, intercompany transactions and month-end reporting. I needed to understand how those figures were produced and what decisions people made from them. Higher utilization could still mean unbillable time, growing variance and less margin on a project. Much of my work involved finding where revenue was leaking or margin was eroding, then tracing the problem back through the process and its data.

That understanding matters when a report looks wrong. One labour-costing review flagged eleven hours of Saturday overtime as a data error. The crew had already reached its weekly straight-time limit, so the whole shift correctly attracted overtime. Understanding the working rotation and pay rules explained the result. Correcting the records without that context would have introduced an error.

I carried that business knowledge into reporting, integrations and the software supporting daily work. The EMS Extension project examples show the connection: validated field time and expenses, better contractor rate matching, and employee time prepared for UKG’s pay rules. Each workflow depended on understanding what the records meant to operations, project accounting and payroll.

How I got here

I came to software from forestry. In 2000, an industry slowdown prompted me to return to school for computer science. When Industrial Forestry Service learned I had been teaching myself C++, they asked me to work on their timber-volume calculation software. I stayed until 2003, writing software full time while attending university full time. My first programming job ran on a VAX mainframe, with no graphical interface or mouse.

I hold degrees in forestry from the University of New Brunswick, biology from Bishop’s University, and computer science from the University of Northern British Columbia. Five years working in remote field camps taught me what crews can realistically capture, where data collection goes wrong, and why software has to fit the conditions people work in. That experience still shapes how I approach a business problem.

I joined Allnorth Consultants in October 2003 and spent twenty-two years there, leaving in April 2026 to run GKC full time. For about seventeen years I developed and maintained their in-house ERP, sometimes with other developers working under me. The work put me close to the people responsible for projects, finance, payroll and field operations.

I later led the migration to BST10. The difficult part was reconciling how the two systems understood the business: revenue recognition, variance and write-offs all worked differently. Over nine months, I scripted the migration in SQL and tested the results so we could complete the cutover over a single weekend.

GKC began in 2012 so I could continue supporting Northern Development Initiative Trust after Allnorth stopped selling software externally. In 2013 I rebuilt the Trust’s ERP, Catalyst, in WPF alongside my day job. It evolved over the following twelve years. When the Trust moved to Salesforce in 2025, I was asked to migrate the data from the system I had built and maintained.

That is the work I want to keep doing: understanding how an operation runs, deciding what should be bought and what needs to be built, and helping it move forward without losing the meaning of its data. The systems should make sense to the people using them and to whoever maintains them next.

What matters in the work

GKC is a Canadian consulting and software company. Business analysis and hands-on development are part of the same service.

Put the client’s interests first: I recommend software because it fits the client’s needs. Assessing existing products comes before proposing custom development. The opportunity to write new software is never a reason to choose it.
Understand the exception: The routine path is only part of the process. I want to know what happens when a record is incomplete, a delivery fails or someone has to make a judgement call.
Make decisions traceable: Field mappings and validation rules need to be understandable to the people responsible for them. With AI, that includes access to source evidence and human review.
Keep responsibility clear: Automation needs a clear point of human responsibility. Someone must be able to review an exception and decide what happens next.
Keep the system supportable: I prefer the simplest architecture that meets the requirement. Documentation and diagnostic tools are part of leaving something another person can understand and maintain.

Have something you’d like to work through?

Tell me what is happening today and what you would like to change.

Discuss a problem gord@gkcdatasolutions.com