Role mission
The Business Automation Analyst turns business needs into working improvements — not just specifications.
They analyze how the company actually works, design better processes, and then automate as much of the solution as they reasonably can themselves: configurations, low-code automations, integrations and AI-assisted workflows. What genuinely needs software engineering they hand over to the development team as a clear, buildable assignment.
This is the analytical and hands-on owner of our business systems — Microsoft Dynamics 365 Business Central (BC) in particular — from the perspective of requirements, processes and automation. It is a step up from a pure support role: the value is in understanding the business deeply and removing manual work, not in answering tickets.
The role does not do first-line helpdesk (L1), and it is not full production software engineering. It sits between the two: business analysis on one side, practical automation and light building on the other.
Main responsibilities
Business Analysis
Understands the real problem before anyone builds anything.
- gathers requirements and runs interviews with users and stakeholders
- maps processes and data flows, identifies edge cases and root causes
- separates "nice to have" from real business impact
- prepares clear inputs and specifications for the development team
Process Automation & Light Building
Removes manual work directly, wherever it can be done without full engineering.
- designs and builds automations (e.g. Power Automate, workflows, integrations)
- configures and extends business systems within their supported limits
- builds small tools and AI-assisted workflows that save the company time
- knows where the line is — hands genuine software work to Product Engineers as a ready assignment
Business Systems Ownership
Acts as the business owner for changes to our business systems.
- owns the backlog, priorities and acceptance for BC and vendor-delivered changes
- agrees solution options with vendors and drives changes to a working, handed-over result
- runs user acceptance testing and validates releases before they reach users
- verifies process correctness and checks data flows and integrations
Adoption, Documentation & Knowledge
Makes sure improvements actually land and stay understood.
- communicates changes, prepares guides and supports onboarding of new features
- documents processes, automations and system rules as part of Business As Code
- collects feedback and turns it into prioritized further improvements
AI-First working style
AI is a core working tool, not an add-on. The role is expected to use AI to:
- analyze processes and draft specifications
- design and build automations and workflows
- generate documentation, guides and test scenarios
- analyze feedback and prepare inputs for decisions
Tools include Claude, Claude CLI, Codex, ChatGPT, AI agents, the automation platform, Jira, Confluence and the internal Business As Code platform.
The point is not to use AI as a chat, but to increase throughput and quality — and to always verify and correct what AI produces rather than shipping it blindly.
How we know you are successful
- manual, repetitive work in the business measurably goes down
- the right problems are solved, and the backlog matches business priorities
- automations run reliably and are documented
- releases are validated and well adopted
- the development team gets clear, buildable assignments instead of vague requests
- business processes are captured in Business As Code, usable by people and AI
Ideal profile — who we are looking for
A rare combination of analyst and builder: someone who enjoys understanding the business and getting their hands dirty removing the manual work. Strong on structured thinking and follow-through, comfortable with data and systems, and pragmatic about where automation ends and engineering begins.
Fits the role
- thinks in processes and data, and likes turning them into working automations
- can hold their own technically without needing to be a full software engineer
- removes root causes instead of just describing problems
Does not fit
- a pure documenter who never builds anything
- someone who wants to code production systems full-time (that is the Product Engineer)
- someone who dislikes talking to users and mapping messy reality
Working with other roles
- Business Owner — aligns on business priorities and process ownership; this role goes deeper into business systems and automation.
- Product Engineer — receives clear assignments for work that needs real software engineering.
- System Owner — cooperates on quality, adoption, release validation and Business As Code.
- Business Systems Administrator — the companion operational role; handles L1 support and day-to-day administration, and escalates analysis, automation and change requests here.
- CTO + Product Builder — guarantor of method and quality; reviews how the work is done.