I work with many organizations and Automation experts. And I am always surprised how few of them use clearly formulated Automation Guidelines. Some of them have formulated no guidelines at all. Some rules are passed down to new employees like Chinese Whispers, but are not mandatory.

Other organizations have a few guidelines which someone has documented sometime in the past.

What does it look like in your company? Do you use Automation Guidelines for your system? Some think of guidelines as a big effort and are afraid that restrictive rules would make it more difficult to find good solutions.

I want to convince you that the opposite is true.

Automation Guidelines are Worth it

If no Automation Guidelines exist, or they are not being used consistently, everyone uses Automic in his own fashion. Most of the time this works beautifully, and I’m sure that you and your colleagues create great solutions.

But what if someone is on vacation or leaves the company? Can the others take over without problems? This and other situations will confront you and your system with challenges which can simply be eliminated with guidelines.

  • With Automation Guidelines all colleagues follow the same principles, making it easier for someone to find his way around someone else’s solutions.
  • You can adapt the Automation Guidelines to your system in a way that optimizes the performance of your system.
  • Jobs and workflows can be transferred and reused more easily.
  • Audits within a standardized environment are simpler and faster. Additionally, the content of your Reports is more informative.

Towards Automation Guidelines in Three Steps

You can formulate your own customized Automation Guidelines with the following three steps. “Customized” is very important here because each system has different requirements and goals and, therefore, needs different rules.

Step 1. WHAT does the AE System need to do?

What demands do you have on your system, what all does it need to solve? Set priorities because your system will not be able to fulfill all requirements. Some frequently needed requirements are: Data security, scalability, transportable solutions, performance, throughput, simple audits, version security of solutions, etc. Note that this is about demands on the entire system, not just individual jobs and workflows.

Step 2. HOW are these demands implemented?

You need to work out the technical methods with which you can fulfill these demands. You set up specific rules for each requirement and each goal. You will see a few examples of such rules in my own guidelines further down the page.

Step 3. DESIGN – The rules are summarized

The best rules don’t help if they are not implemented. Therefore, in this step, the rules are clearly formulated in four categories:

  1. Rules, for instance, “use object variables”.
  2. Best Practices, for instance, “if possible, use visible tasks”
  3. Dos, for instance, “use prompts and object variables”
  4. Don’ts, for instance, “do not make jobs dependent on inheriting variables and values”

With these rules you will then create templates for objects, and you can even create prototypes, i.e.,dummy workflows that can be used as drafts or for the training of new employees.

My Guidelines for Working with Automic

I develop many solutions, not for me but for my clients. Of course, this has an effect on the demands for my solutions.

Here are my most important WHATs:

Easy Audits and Reports

Reusable objects on my system and all other systems

User friendliness, the client has to be able to manage the solution

Transportability, meaning problem-free transport from DEV to TEST to PROD

Next, I document the technical methods for fulfilling the requirements. Here are a few examples:

AV entries

In the Archive Values (AV), PRPT variables, object variables, and the values for all statistic sets are stored.

No environment dependencies

Jobs are not dependent on the environment. Not on the AE and the Client, and also not on Workflow and on a specific context. Therefore, Jobs may not inherit variables from their parents.

When possible, use visible tasks

Visible tasks make it possible for the user to see immediately what’s happening.

Use Config-VARAs

Storing the configuration in VARA objects makes it possible for all objects on DEV, TEST and PROD to remain the same.

I utilize several rules for each requirement. Here is a brief overview of what these rules could look like:

Guidelines for You and Your Organization

To use guidelines is easy – to create them is not. As you have seen, it requires a detailed analysis of the demands on your system and a planning of methods.

An important aspect of guidelines is the ability to check automatically if they can be observed. This may not work for all defined measures, but most of them should be able to meet the requirement.

Whether a retooling of your old jobs and workflows into new or updated Automation Guidelines makes sense, depends on many factors. Usually it does not make sense to do so with current and well-functioning solutions just to adapt them to your new standards.

By the way, it does not hurt to call on external help for the guidelines. As an outsider, one has a different view of the system and is not caught up in internal processes. At the same time, cockfights are avoided regarding whose practices should serve as a model for the guidelines.

If you would like to consult someone, simply contact me. I will be happy to support you.