From the first automation to an in-house solution: developing an internal maker

1. Internal solution builders already exist in most organisations

In almost every company there is someone who has already improved their own work with an advanced Excel file, a form or a simple automation. They know the process well and are strongly motivated because they are solving a real problem from their day-to-day work.

Access to the tools alone, however, is not enough. Without a suitable first use case, basic rules and support, the first automation can quickly become unreliable or dependent on a single person.

2. The first step: one small, understandable automation

The first goal should not be a complete application, but a simple flow that removes one repetitive task. The builder needs to understand what triggers the automation, which data it uses, what happens when it fails and how it can be changed.

Suitable starting examples are:

• saving form data to a shared list,
• saving attachments to a specific folder,
• an automatic notification when a status changes,
• a reminder before a deadline.

Success is not just that the automation works on day one. What matters is that the builder can later check it, fix it and explain it to a colleague.

3. From a personal aid to a team solution

Once more people start using a solution, new questions arise: who is allowed to see the data, who can change it, who is notified when something fails and who is responsible for maintenance.

At this stage, personal files need to be replaced with shared, properly governed data sources. Naming, documentation, testing and an agreed way of releasing changes also become important.

A solution that runs only under its author's user account, or that only one person understands, is a business risk.

4. Processes that span several departments

The next level of complexity is processes with approvals, exceptions, escalations and an audit trail. Here technical knowledge is not enough. First it has to be clear how the process should run, who decides and which exceptions are justified.

An internal builder needs to be able to map the process, separate the normal flow from the exceptions and recognise when to involve the process owner, the environment administrator or a professional developer.

5. When it is time for an application and more advanced knowledge

It makes sense to move forward when several of the following needs arise:

• a wider group of employees uses the solution,
• users need a tailored user interface,
• the process involves several roles and different permissions,
• the solution connects to other systems,
• reliable change management and support are needed.

At that point, it makes sense to expand that knowledge to include application design, data modelling, security, integrations, testing and solution lifecycle management.

6. Internal development needs clear rules

An organisation has to define which types of solution employees may build on their own, which need a review and which require professional development.

The important criteria are business criticality, data sensitivity, the number of users, connections to other systems, regulatory requirements and the consequences of a possible failure.

The purpose of the rules is not to limit initiative, but to prevent solutions with no owner, documentation and support.

7. A BizIT example

For several clients, we support internal builders with workshops and one-to-one coaching based on real use cases. The participant brings their own process or solution, we improve it together and explain good practices along the way. That way the knowledge stays in the organisation, while the risks that arise from developing without proper support are reduced.