Internal Systems
Purpose-built internal software for operational processes that have outgrown spreadsheets, local databases or disconnected tools, with clear data ownership and permissions.
Many organisations run important work from a spreadsheet or small database someone built years ago. It works while that person is around and while there is only one copy. Eventually there are several versions of the same list, and a process stops when one staff member takes leave.
Support the process, do not just replace the file
The objective is software that matches the actual operational process, with clear data ownership, permissions and operational behaviour. Different data may legitimately have different authoritative systems. A custom internal application does not automatically become a single source of truth for everything.
The work may replace an existing tool, extend one, or introduce a purpose-built layer around CRM, ERP, accounting, identity or other systems. Replacing a spreadsheet does not automatically justify a large platform. The scale should match the importance and complexity of the process. If a suitable existing product can meet the requirement at acceptable cost and risk, that should be considered first.
Common starting points
Only one person can run it
The process depends on someone who understands the formulas, macros or hidden tabs.
Copies that disagree
Different teams keep their own versions, and reconciling them takes time every month.
No useful control over access
Anyone with the file can see and change everything, and there is little record of who changed a figure.
What we do
Document the current process
The process and its exceptions are recorded as they are actually run, including spreadsheet formulas and workarounds.
Define ownership
We decide which system owns which data, who can see and change it, and how changes are recorded.
Build the workflow and records
Applications, roles, permissions and reporting for the process, with migration of the data that is still needed.
Add audit where the process needs it
Where an approval or figure must be traceable, the system records who did what and when.
What you end up with
One shared record
A single place for the process data, replacing the several copies that teams keep separately.
Permissions and an audit trail
Access matched to roles, with a record of changes where the process requires one.
A process that does not depend on one person
The steps, rules and exceptions are documented and built into the system.
How a typical engagement works
Old and new often run side by side for a period while staff check the results. Once the new system has handled a representative cycle, the old file can be archived so it does not quietly return to daily use. The exact sequence depends on the process and the risk of getting it wrong.
01Document
Document the process
We follow the current process through a representative cycle and record its rules and exceptions.
02Design
Design the records and workflow
Data ownership, roles and the workflow are agreed before the build starts.
03Build
Build and migrate
The system is built in stages and the data that is still needed is migrated and checked.
04Cutover
Run side by side, then cut over
Old and new often run together while staff check the results, and the old file is archived once the new system has handled a representative cycle.
05Support
Support after cutover
After cutover, support can continue as the process changes.
Frequently Asked Questions
Start with a conversation
Book a free 15 minute call. Describe the problem, the systems involved and what you already know, and we will tell you plainly whether we can help and what a sensible next step looks like. There is no obligation.