Automation
What to automate in an SME: Diagnosis and Priorities
Before automating, it is advisable to diagnose which task produces enough repetition, error or wait to justify the change. A useful candidate follows recognizable rules, has verifiable entries and allows measuring the result; a confusing or exceptional task usually needs order before technology.
This guide works as a diagnostic and prioritization criterion: what to automate, what to leave for later and when not to automate. To turn a chosen opportunity into a first stream, see the Automation Guide for SMBs.
When it's worth automating
A good candidate usually combines three signals: it is repeated frequently, its rules can be explained, and the result can be checked. If any of them are missing, perhaps the first step is to sort the process.
Exempla hypothetical: if each application received must always be registered, assigned and notified in the same way, there is a clear pattern. If the assignment changes in each case according to criteria that no one has documented, then first it will be necessary to define those criteria.
Which items should be reviewed before automating
Not every repeated task needs immediate automation. To decide if a process deserves attention, check these elements:
Defined Chained. Identify what starts the flow: the arrival of a form, a change of status, a date, receipt of a document or an approval.
Repeatable steps. Describes actions that are almost always done the same. If each case requires a different decision or hard to interpret information, the process may first need a clearer rule or a human review.
Input and destination data. Lists what information you enter, where it comes from, and where it should be recorded.A flow is not sufficiently defined if it is only indicated that you must "connect" two tools.
Responsible for exceptions. Defines who acts if a data is missing, an error occurs or the case does not fit the usual rule. Automatizing does not eliminate the need to manage exceptions.
Probable result. Formulate what should happen at the end of the flow.For example: the request is created with the required fields, the right person is notified and the status of the shipment is recorded.
Access and maintenance. Clarify who controls the accounts, credentials and tools involved, and who will be able to review or modify the flow when the process changes.
How to prioritize automation
When there are several options, compare them with the same criteria. You don't need to make the decision into a formula: you just need to distinguish which processes are clear enough to start.
| Criterion Ask to Decide | |
|---|---|
| Impact on the | Process What specific problem reduces or avoids? |
| Frequency How often is the task repeated? | |
| Clarity of | Rules Are the steps and exceptions defined? |
| Dependencies What tools, people or data should be available? | |
| Risk of | error What happens if the flow is executed incorrectly? |
| Validation facility | How will you check that the result is correct? |
It prioritizes processes with a clear goal, stable steps, and an easy-to-check result. If a flow depends on informal decisions, incomplete data, or integrations that are still unknown, make it clear before building it.
The scope should also be separated into three groups:
-Impensible: the necessary for the flow to solve the initial problem. -Desirable: useful improvements that can wait for a second phase. -Future: documented ideas, but they are not incorporated into the first release.
This separation prevents simple automation from becoming a project that is difficult to check and maintain.
Example applied: managing requests received
Exempla hypothetical: a company receives requests from its website. A person checks the data, copies it to an internal tool, assigns the contact to a responsible person and sends a notice by mail. The problem is not in a single task, but in the sum of small steps that are repeated with each request.
The aim would not be to “automate forms”, but to reduce manual steps following a full application.
A first version could include:
- Receive the form details.
- Validate that the fields defined as necessary are present.
- Create a registry in the agreed system.
- Assign the application according to a previously defined rule.
- Send a notification to the responsible person.
- Register if the flow is completed or requires revision.
Instead, advanced classification of messages, complex business rules or connections with tools that have not yet been clearly responsible could be left for a later stage.
Before starting, the team should agree on acceptance criteria. For example: when a request contains the required fields, a single record is created, the corresponding person is assigned and the expected notice is generated. If data is missing or a connection fails, the case is identified for review.
What should be left out of the first automation
The first version must solve a defined problem, not to reproduce at once the entire operation of the company. It is usually prudent to postpone:
- Integrations whose operation or access has not yet been confirmed.
- Rules that the team still applies differently depending on the case.
- Decisions requiring an informal trade, technical or human context.
- Data migration without inventory or cleaning criteria.
- Reports or panels that have not been defined in terms of users, data and decisions.
- Functions that cannot be tested with a concrete result.
Leaving these points out does not mean discarding them. It means preventing them from conditioning a first delivery that should be able to prove, correct and maintain unambiguously.
Next step: define the flow before asking for budget
If you want to contrast if that process is sufficiently defined, you can request an initial assessment of the need and its scope and explain the process to AVSISTEC.