We fix the report that takes ten minutes and sometimes doesn’t finish.
Usually it comes back in seconds afterward, and the reason isn’t a faster server or a better reporting tool. It’s that the work moved to where it belongs — into the data, before the report ever opens. We’ve been doing that particular job since 1999, for organizations whose reporting is the thing the business actually runs on.
Before you scope anything
“I thought this system could handle that.”
It’s the most common sentence in the room when a technology project meets its first real reporting requirement.
Reporting is the one part of a system that everybody assumes is handled. It rarely appears on a requirements list, because it doesn’t feel like a feature — it feels like something that obviously comes with the software. So it gets left out of scope, and then six months in someone asks for a figure broken down a way nobody anticipated, and it turns out the system was never designed to answer that question. Now it’s a change order, and it costs more than it would have in week one.
We ask about reporting at the beginning, before anything is built. Not “what reports do you want” — that list is always incomplete — but what questions the business needs answered, who needs to answer them, and how current the answer has to be. Systems designed around those questions can answer new ones later. Systems designed without them have to be opened back up.
It’s built in, not bolted on. Every product we’ve built and every application we run has reporting designed in from the start, including our own SaaS platforms. That’s the short answer to whether reporting will be a problem on a BKY project: it’s a question we asked you before we quoted.
The short version
Reporting is two jobs, not one.
The word covers two kinds of work with almost nothing in common. Sorting out which one you’re asking for is usually the first useful thing that happens, because a business that knows the difference stops shopping for the wrong tool.
Documents that have to be exact
Statements, dues notices, invoices, cheque runs, tax receipts, inspection reports, the board package. They get printed, signed, mailed, filed, and sometimes produced years later. They have to land on the page correctly, look identical every time, and be reproducible in three years. Precision is the entire requirement.
Decisions that have to be current
Which jobs are losing money, whether we’ll hit the number, what changed since Friday. Looked at on a phone between meetings, filtered and pulled apart. Nobody prints them. Being current matters more than being beautiful.
What usually went wrong. A business bought a tool for the first job, then spent fifteen years asking it to do the second, because it was the reporting tool they had. That’s how a report ends up taking ten minutes. The tool didn’t fail — it got assigned the wrong job.
Where these start
You probably came here saying one of these.
You don’t need to know what to call it. Describe it the way you’d describe it to a colleague and we’ll work out what it actually is.
“This report takes ten minutes and sometimes crashes.”
Someone has learned to start it and go do something else, and to try again when it dies. This almost always means the calculating is happening inside the report, row by row, instead of in the database beforehand. Known shape, known fix, and the fix is usually not a new tool.
“Two systems, two answers.”
Payroll says one thing, the field app says another, and the meeting stops while two people defend their spreadsheets. This is what happens when the same figure is defined in more than one place and both definitions drifted. It doesn’t get solved by picking a winner.
“The person who built our reports left.”
Undocumented reports nobody dares change. Reading other people’s undocumented systems is a specific skill, and one of our senior developers is known internally for exactly that.
“We bought a dashboard tool and nobody opens it.”
Usually because it shows figures people don’t trust, or figures that don’t answer a question anyone actually has. Both are data problems wearing a dashboard costume.
“Month-end takes three days.”
Most of it one person exporting, pasting and reconciling by hand. Every manual handoff is a place where numbers drift apart, and it’s work that doesn’t need a person doing it.
“Nobody can tell me how that number is calculated.”
Act on this one soonest. If your organization can’t check the total, the total isn’t information — it’s a rumour with a decimal point.
How we approach it
The first question isn’t what you want to see. It’s how current it has to be.
Most of this work is decided before anyone opens a reporting tool. Four steps, in this order, every time.
Inventory the information assets
Find out what data exists and where it actually lives. Usually more places than anyone expects: the ERP, the field application, a payroll platform, three spreadsheets, and something built in Access in 2011 that turns out to be load-bearing.
Establish how current each answer has to be
The question that decides the architecture, and almost nobody gets asked it. Real-time, hourly, overnight, monthly? A figure that has to be live is a completely different build from one that can be an hour old — and most figures people ask for live don’t need to be.
Build the data layer and prove it answers the question
We consolidate and clean the data into a single source, then break the list of wants into specific views — one per question the business needs answered. Before anything gets presented, we confirm each question can actually be answered correctly.
Then build the presentation layer
Only now does the tool get chosen: Crystal, Power BI, paginated reports, a scheduled email that lands in an inbox every Monday. Whichever fits the job.
Who does this. The gathering is done by business analysts and project managers, not programmers — people whose job is understanding how your operation works. That’s why we can explain your reporting back to you in language you can check, and why the conversation starts with your business rather than our technology.
Your live systems
We don’t touch the system your business runs on.
Most reporting problems live on top of a database someone else manages — a large ERP, a vendor-hosted platform, something with a support agreement and rules about what you’re allowed to change.
So we don’t change it. We build a separate reporting database and bring the data across on a schedule. Nothing gets added to the vendor’s system, no objects get created in a database we don’t own, and heavy reporting queries stop competing with the people trying to enter orders. Your reporting gets faster and the production system gets left alone — including its support agreement.
It also means we can consolidate across systems that were never meant to talk to each other, because the place they meet is ours. And we can work with essentially any database we can get a standards-compliant connection to, which after twenty-seven years is most things.
The industry calls this a data warehouse. What it means is one place where the numbers agree.
Where it runs. Azure SQL Managed Instance, in Canadian regions when your board or your membership needs the data to stay in Canada. Backed up and monitored the same way as everything else we host — because we host it.
How we build it
The tool should be presenting, not compensating.
One conviction we’d ask you to hold us to: the heavy lifting belongs in the database, and the tool’s job is to present the result clearly and pleasantly. Four things follow, and you’ll notice all four.
It’s fast
The aggregation is finished before the tool sees the data. That’s the difference between a report you run and a report you schedule your afternoon around.
Everyone gets the same answer
When a figure is defined in one place, every report, dashboard and printed statement drawing on it agrees. When it’s defined inside each report, every report is its own private version of the truth.
You’re not locked in
Change the presentation tool and you keep everything that mattered. When business logic is buried in the reports themselves, changing tools means rebuilding your business rules from scratch — which is the real reason report migrations get quoted as frightening numbers.
It’s checkable
One documented place where each figure is defined, which is what lets us explain a calculation in terms you can test: which records are included, which are excluded, and what happens at the edges. If we can’t explain how your numbers are calculated in plain language, that’s our failure, not a gap in your knowledge.
We’ve been saying this in writing since 2008. Anyone can produce a report with a total on it. The question is whether your organization can check that the total is right.
Right tool, right job
Three tools, three different jobs.
We don’t resell any of these and we don’t have a favourite. Here’s what each is actually good at, so you can tell which conversation you’re having.
Crystal Reports
Documents that have to be exact. Still the most effective pixel-precise tool for traditional documents intended to be printed on paper, which is why a great deal of what our clients post and file is produced in it.
Paginated reporting
The same job on a current platform. SQL Server Reporting Services and Power BI Paginated Reports do exact-document work on an actively developed stack that integrates with the systems around it.
Power BI
Decisions that have to be current. Interactive, filterable, refreshed on a schedule, works on a phone. The right tool for the second job and the wrong tool for a cheque run.
And none of them is why a report is fast or a number is right. That’s decided underneath. Choose the tool last — it’s the easiest decision on the list, and the one every vendor wants to make first.
On the newest thing. There is always a new platform being pushed hard, and some of them carry licensing that costs more per year than the questions being asked are worth. We won’t put your reporting somewhere that only makes sense at a scale you don’t have. For most organizations, well-built views on a database you already pay for answer the same questions — and we’ll tell you when that stops being true.
Crystal Reports
Where Crystal Reports fits.
A great many of the documents our clients send out are produced in Crystal, and most of them should carry on being produced in Crystal. For output that goes on paper it remains the best tool we know — the layout holds, the pagination is predictable, and it runs the same way every time. If it’s working, that isn’t a problem in need of a project.
Where we do get involved is when a Crystal report has been handed the other job — a manager opening a printed statement to make a decision, because that’s the report that exists. That doesn’t call for a migration. It calls for the decision to have its own report, built on data already prepared to answer it, while the statement run carries on doing what it does well.
Questions about your version? Support windows differ by release, and what they mean in practice depends on how your reports are deployed rather than on the date itself. If it’s on your mind, ask us and we’ll go through your situation specifically. It’s a short conversation and it isn’t a sales call.
Your dashboard
You decide what matters. We build it and show you the arithmetic.
We don’t arrive with a template of the twelve metrics every business should track. You already know what you watch — the figures you ask for in a meeting, the ones you check on a Monday, the one that tells you early when something is going wrong. Our job is to find where they live, make them agree, and put them somewhere you’ll actually look.
So the first conversation is questions, and they’re about your operation rather than our technology. What decision are you making? How would you know if it went badly? Who needs to see this, on what device, and how current does it have to be?
Then you get the part most dashboards don’t come with. For every figure on it, we can tell you which records are counted, which are excluded, and what happens at the edges. You should be able to challenge a number on your own dashboard and get a straight answer.
Different audiences get different reports. The board’s view, a department manager’s view and a staff view are built as separate reports on separate views of the data, rather than one report with rules trying to hide rows from certain people. It’s simpler, it’s easier to audit, and you can hand someone a report knowing exactly what’s on it — which matters more than clever when the subject is who gets to see whose numbers.
Whatever you already own. If your team is already in Power BI, we build into it. If you have nothing, we’ll recommend something and tell you what it costs to run. Because the work that makes it fast and correct doesn’t live in the tool, this is a smaller decision than it’s usually made to seem.
When it’s genuinely hard
Some reporting is difficult in ways a chart doesn’t capture.
Most reporting is straightforward once the data is in order. Some isn’t — and the hard cases are where twenty-seven years of doing this stops being a line on a page and starts being the reason the report works. It’s worth saying where they are, because it’s where the job stops being about tools at all.
-
Inspection and NDT
The hardest reporting we do. Non-destructive testing collects data in nested layers — readings within locations within components within assets — and the report has to convey that structure on the page so a reader can follow how the inspection was actually performed. Hierarchical grids that stay legible are difficult to build and unforgiving to get wrong. Advanced techniques like guided wave testing and pipeline integrity inspection push it further again.
-
Healthcare
Complex requirements, and the reporting has to be right in a setting where being wrong has consequences beyond an awkward meeting.
-
Workplace organizations
High volume, comparatively simple structure. Thousands of statements and receipts that have to be correct and go out on time — a different kind of difficulty, and one where speed of generation is the thing that matters.
Reporting is in everything we ship. Both of the SaaS products we built, host and run have reporting designed in, across seventeen organizations and roughly 66,000 members. It isn’t a service line bolted onto a development shop — it’s how we build.
How this goes
How this actually goes.
We look at one report
The slowest one, or the one two systems disagree about. Small enough to tell you something real, cheap enough that nobody needs approval.
You get the diagnosis in plain language
Why it behaves that way, where the figure is actually defined, and what a fix would cost. Sometimes one rewritten query fixes it and the project you were budgeting for isn’t necessary.
We build the layer underneath
Scoped in writing with acceptance criteria agreed in advance. Consolidation from your source systems into one place the numbers agree, documented well enough that someone other than us could read it.
Then the presentation, and then we run it
Built to what you told us matters, in the tool that fits. Hosting, scheduled refreshes, and changes as the business changes — the same as everything else we look after.
Where to start
Pick the report everybody complains about.
Every organization has one. The report that takes ten minutes, the figure two departments argue over, the statement run that ties up an afternoon every month.
Tell us about that one. We’ll look at where the data comes from and how it’s being produced, and give you a straight answer on why it behaves the way it does and what fixing it would cost. No charge and no obligation — the first conversation and the preliminary meetings are free, the same as every engagement we take on.
If the fix is small, we’ll tell you it’s small. That costs us the bigger project and keeps the client, which is a trade we’ve been making since 1999.
Questions
What people ask before they start.
Why is our report so slow?
Almost always because the work is happening inside the report rather than in the database. When a report pulls thousands of rows and does the calculating itself, more hardware barely moves it and a new reporting tool moves it less. Do the aggregation in the database first and the same report comes back in seconds — we’ve taken ten-minute reports that regularly crashed down to a few seconds without changing the tool that displays them.
Why do two systems give us different numbers?
Because the same figure is defined in two places and the definitions drifted. The fix isn’t deciding which system wins — it’s building one place where that figure is defined and having everything read from it.
Do we have to replace Crystal Reports?
Usually not, and not all at once. Crystal remains supported, though your specific version has its own date. It’s also still the best tool we know for documents destined for paper — we build in both, and for a statement run or a cheque print our advice is normally to leave it where it is. What tends to force a move isn’t the support date but the architecture around it: an embedded runtime, an ageing report server, or an application upgrade that won’t carry the old reports along.
Will you need access to our ERP or our vendor’s database?
Read access to get the data out, and nothing more. We build a separate reporting database rather than creating objects inside a system somebody else supports, so there’s nothing to void a support agreement and no heavy reporting queries competing with the people using the live system.
Can different people see different numbers?
Yes, and we do it by building separate reports on separate views of the data rather than one report with rules trying to hide rows by audience. Rule-based hiding gets cumbersome quickly and hard to verify. This way you can hand someone a report and know exactly what’s on it.
Can you report on our database? It’s not SQL Server.
Almost certainly. We work with any database exposing a SQL-92 compliant connection, which covers essentially every commercial and open-source database in use — including whatever sits under your ERP. Because we copy the data into a separate reporting database rather than reporting against yours directly, your platform doesn’t constrain what we can build on top of it.
Do you build in Power BI?
Yes, and in Crystal Reports, SQL Server Reporting Services, Power BI Paginated Reports, and scheduled email where that’s the right answer. We’re deliberately not tied to one, because the tool is the presentation layer. What determines whether reporting is fast, correct and still working in five years sits underneath it.
Do we need a data warehouse?
Sometimes, and the term does more harm than good. What organizations actually need is one place where the numbers agree, built from the systems that hold them. For some that’s a genuine warehouse; for plenty of others it’s considerably smaller. We size it to the questions you need answered rather than to the term.
We already have someone who writes our reports. Is it worth calling?
Often no, and we’ll say so. Where we tend to add something is when reports are slow for structural reasons, when systems don’t talk to each other, or when nobody left can explain how a figure is produced. If your reporting is fast and trusted, that’s a good position and we’d rather not sell you out of it.
Where are you, and does this need to be local?
Edmonton, with operations in Calgary as well. Reporting and data work doesn’t require anyone in your building — we do this for organizations across Canada and into the United States. Our managed IT practice has a hard geographic limit because it involves people driving to buildings. This doesn’t.