Software should fit the organization.

Where time and effort get lost

Most conversations start with a problem like one of these:

Repeated work

The same figures typed into two systems, or copied from email into a spreadsheet.

Reports by hand

A monthly report that someone assembles from several sources over two days.

Scattered information

Answers kept in shared drives and inboxes, or a process that works because one person knows how the pieces fit.

Software that doesn't fit

A product the team works around, with a spreadsheet beside it for what it won't hold.

Work that might be automated

A task that wasn't practical to automate a few years ago and may be now.

The way an organization works usually exists for good reasons, and its people know their tools well. That knowledge is worth keeping, so we learn how the work is actually done before recommending anything.

What happens when you get in touch

Conversation

You describe the problem, and we ask about the people and systems involved. You talk directly with Randall Smith, the engineer who would do the work.

Assessment

If the problem needs a closer look, we propose a paid assessment with a fixed scope. We watch how the work is done and examine the systems and data involved. You receive a written report that is yours to keep and to use with any vendor.

Options

We lay out the practical choices with their costs: software you already own, a product you could buy, an integration, a process change, automation, AI, or something custom. You see the reasoning, so you can tell us where you know something we don't.

Implementation

If you decide to go ahead, the work is scoped and priced separately. The assessment doesn't commit you to it.

How we weigh buying against building

Off-the-shelf software is often the right answer, but its full cost usually runs past the quote. A product demonstration shows what the software can do. It can't show what the software has no place for. Those gaps get filled with workarounds: a spreadsheet for the fields the product won't accept, the same figures entered in two systems, and eventually someone whose real job is being the bridge between them. After a few years, leaving the product is usually a bigger project than installing it was.

Custom software has its own cost, which is everything that has to be maintained, so we build no more than the job needs. Where a product fits the work, we'll recommend buying it.

Who does the work

Berryman Data Systems is Randall Smith's practice. He has spent more than twenty-five years building and maintaining production systems, much of it for public agencies. He came to this work through practical process improvement: replacing searches through paper files with database reports, writing parsers for instrument results that had been copied by hand, migrating legacy data systems, and connecting software that needed to work together. Most engagements are ordinary application and data work.

Most of a system's life comes after delivery, and the client owns all of it. The source code, the data model, the documentation, and the steps to deploy it are kept in the client's own accounts from the start, so any capable engineer can take the system over. We write the code and the documentation for that engineer.

Regulated data and drinking water

The firm's principal has worked longest with regulated data: systems built around federal data standards and legal deadlines. Most of that work has been in drinking water, including SDWIS/State, the DW-SFTIES transition, and EPA reporting. That work has its own page.

SDWIS/State, DW-SFTIES, and drinking water data systems