The right first change is the smallest coherent change that solves the actual problem. Look at the work, the available tools and the cost of operating what comes next.
By Blake A. Jones · Systems solutions and integrations consultant Published · Updated
Improve when the tool is capable but the process is unclear
Start with configuration, shared definitions, templates and a clear owner when existing software already supports the required task. A well-structured spreadsheet can be entirely appropriate.
Example: missed follow-ups may come from unclear responsibility rather than a missing application. Test a shared queue and an agreed review habit before commissioning a new system.
Integrate when good tools lose context between them
A connection is worth exploring when useful information must repeatedly move between systems. Define which source owns each value, permitted access, refresh timing and how conflicts will be handled.
Example: two teams re-enter the same job details. A pilot can test one transfer and its exceptions. Check vendor API availability and costs before assuming integration is feasible.
Build when the workflow needs a capability the tools cannot provide
A custom interface or analytical tool may fit when the business needs distinctive calculations, review steps or data relationships that existing products cannot reasonably support.
Prototype the difficult part first. Define acceptance examples, source access and operating ownership. Include documentation, maintenance and an exit or export path in the decision.
Compare the options against the same problem
For each option, record workflow fit, implementation effort, recurring cost, data portability, staff adoption, permissions, vendor dependencies and recovery needs. Separate known costs from unresolved questions.
Try representative records and edge cases, not just a polished demonstration. Consider missing data, failed updates and what happens when the usual operator is unavailable.
Use AI where its behavior can be checked
AI may help draft, summarize or organize information; it also introduces uncertainty and review needs. Decide what must be correct, how mistakes will be detected and who can authorize the next action.
A deterministic rule or an ordinary form is often sufficient. Neither an AI label nor a custom build is a business outcome. Choose the method by what it can reliably contribute within the agreed scope.
Make the first decision reversible
Define a discovery brief and one bounded pilot. Agree what would support expansion, what would require revision and what would justify stopping. Preserve a working fallback while evaluating a change.
Blake’s portfolio shows approaches to inspectable workflows and analytical interfaces. It provides evidence of the approach, not proof that a particular solution will work in your environment.
Where AI-assisted implementation fits
Agentic AI can assist with configuration, integration and custom implementation. The delivered workflow may use ordinary rules and interfaces. Compare these options against the same acceptance examples and operating responsibilities.
A useful first scope Map one recurring process, identify its exceptions, and prototype one repeatable step with a human review point. Establish a baseline before deciding what to automate.
Relevant evidence Mission Lab shows bounded execution and revision; DOAPO separates a proposal from authorization.
The team cannot trace a report back to a trusted record.
A useful first scope Choose one decision and a representative dataset. Build a reviewable view that exposes definitions, source context and the next action before expanding to more users or data.
Relevant evidence DOAPO organizes records for review; Horizon RWT exposes data mapping and analytical checks.
A useful first scope Review one boundary between systems: what information crosses it, which source owns each value and what happens when an update fails. Test an incremental path before proposing a replacement.
Relevant evidence Horizon RWT demonstrates imported-data handling; Renigma provides structured modeling perspectives. These are related capabilities, not proof of a deployed business integration.