Automation Competency Center: Roles and Ways of Working

Why automation often "stalls" after deployment

Stalled automation looks the same in many organizations: the system is launched, people use it actively for a few weeks, and then improvements stop. Formally, the tool exists, but it increasingly does not match how work is really done. People gradually return to Excel, chats and workaround procedures.

You usually notice this from simple symptoms. There is no one steering the direction: what to do first, what can wait, and what must not be changed. There is no single prioritized queue for improvements, so requests get lost in chats and emails. Changes are made "on request": whoever asks the loudest gets the tweak. Over time the system becomes patchy: too many buttons in some places, mandatory fields kept just for show, and reports that don't match reality.

This happens even with a good vendor and a reasonable budget, because implementation and development are different tasks. The vendor is responsible for launching according to agreed requirements, but after launch "life" begins: processes change, regulators add requirements, org structures and products evolve. If the company has no roles and rules for handling changes, the system will inevitably lag behind.

The losses are not limited to employee time. Data quality falls: people enter values casually just to "move on." Reports stop being reliable, and managers start doubting the numbers. Worst of all, trust erodes: if "the system always lies," people stop trying, and restoring discipline later becomes much harder.

A typical example: sales ask to add a couple of statuses, finance needs new payment fields, service adds its own categories. Without an owner and a common logic this turns into dozens of fragmented changes that conflict with each other and break analytics.

What is a competency center and why the company needs it

An automation competency center is a small ongoing team (or role-function) responsible for developing automation so the system provides value instead of becoming "set and forgotten."

It's not the same as the IT department. IT usually maintains infrastructure, access, security and general system operability. The competency center is closer to internal product management: it helps the business choose what to automate, agree on common rules and change processes without chaos.

The center has clear boundaries. It doesn't do users' work for them or "carry everything on its back." It doesn't replace managers who make decisions and are accountable for results. Instead, it brings order: making changes manageable and predictable.

Typically the center is responsible for:

• a single backlog of requests and prioritization by value rather than by volume;
• change rules: who approves, how we test, how we roll out;
• user support and a knowledge base so the team doesn't answer the same questions repeatedly;
• data quality and unified reference data to keep reports consistent;
• clear metrics: what's been implemented, what improved, and where things are stuck.

A daily example: in a company with several procurement and accounting teams, the same enhancement request can arrive five times in different words. The center consolidates these into one task, clarifies the goal, agrees a single scenario and implements the change so it doesn't break other teams' work.

After 3–6 months the effect is usually noticeable: fewer fires, faster approvals, a clear work queue, fewer manual Excel workarounds and regular scheduled system updates.

Roles in the competency center: minimal set and scaling

To prevent automation from stalling, the team's size matters less than ensuring key responsibilities are covered.

The minimal set is usually:

• Product owner: responsible for business value and priorities.
• Analyst: converts requests into requirements, documents processes and monitors data quality.
• System administrator: ensures stable operation, access control and user support.

When requests increase, responsibilities start to spread thin, gaps appear and quality drops. Then the center can be expanded selectively: add an architect (to prevent conflicting solutions), a tester (to avoid breaking functionality), a training and communications specialist (to help users accept changes), and sometimes a support coordinator.

Priorities should be approved in a clear governance loop, not in private chats. In practice a product owner may report to a business leader or IT, but major changes are better confirmed by a short committee: business, IT, security. This reduces the "loudest gets what they want" problem.

If staffing is limited, roles can be combined. That's fine, but risks should be discussed in advance. A product owner who also does analysis often loses an outside perspective and may set unrealistic expectations. An analyst who also tests is more likely to miss bugs. An administrator doubling as product owner may unintentionally bias priorities toward ease of maintenance rather than business value.

A good guideline even with combined roles: it must be clear who makes final prioritization decisions, who is responsible for requirement quality, and who ensures system stability.

The product owner role: focus on value and development

The product owner in the competency center is not responsible for "doing tasks" but for the system's value and evolution. Their responsibilities include goals and measurable value, priorities, initiative selection rules, and allocating budget and time for improvements (not just support).

After launch there is almost always a stream of diverse requests from units. The product owner must gather them into a single backlog, format them consistently and discard items that don't deliver value or violate common rules.

A short intake filter before work starts helps:

• what business problem are we solving and for whom;
• how will we measure the result (time, errors, money, risks);
• is this a one-off request or a repeatable process;
• what dependencies and risks exist (data, access, integrations);
• who is the business process owner.

To avoid changes "hanging" for months, the product owner sets clear Definition of Done criteria. For example: scenario agreed, fields and data sources documented, rights configured, a test case exists, and a short user guide prepared.

Show progress with simple metrics, otherwise trust quickly falls. Usually 3–4 indicators are enough: request-to-release lead time, share of features actually used, user satisfaction, and measurable impact (e.g., N hours of manual work saved per month).

Example: in a company with multiple sites two departments request "urgent fields added to a form." The product owner discovers that one needs the fields for reporting, while the other needs them to reduce returns due to errors. The latter is prioritized because its effect is immediate, while reporting can be solved with a standard export without changing the whole form.

The analyst role: requirements, processes and data quality

An analyst turns scattered wishes into tasks that can be built and verified. Requests often sound like: "we need a button" or "do it like before but in the system." The analyst clarifies the desired business result, where the process breaks and how success will be measured.

A practical approach is to start with a short description of the current process: who initiates, what steps are taken, what documents are used, where approvals happen, and what exceptions exist. Then capture the target state: what changes, what stays, and who is responsible for each part. This reduces disputes before development begins.

To keep interviews focused, use a simple framework:

• how is this done now and why;
• what commonly goes wrong (errors, delays, duplicates);
• what exceptions to account for;
• which fields are mandatory and where data comes from;
• how you'll know it's better (time, quality, reporting).

Part of the analyst's responsibility is data quality. If reference data, statuses and filling rules are not well thought out, reports start to "lie" and trust in the system declines. The analyst describes entities and reference data in plain language: what is a "counterparty," a "request," an "stage," which values are allowed and who maintains them.

The analyst's output is clear requirements and scenarios. These should define boundaries and validations: what the user sees, what the system checks, what notifications are sent, and what counts as an error. For example, for a procurement request, describe scenarios like "approved with changes" and "returned for revision" so configuration and testing are predictable.

The administrator role: stability, security and support

The administrator keeps automation running every day and prevents it from becoming a set of manual workarounds. In the competency center this person maintains the system: access, updates, backups and a clear path for production changes.

First area: access and roles. If access is granted "by request in chat," over time excessive permissions, shared accounts and leakage risks appear. A basic practical approach: document roles, issue access by request, and regularly remove unnecessary permissions.

Second area: change control. Any update, integration or even a reference data edit can break reports or business rules. The administrator helps enforce order: what we test, who approves and when we deploy.

Third area: user support. It's important not only to "help on call" but also to manage a queue of issues, identify common questions and turn them into short instructions. If the same mistakes occur weekly when creating requests, add hints to the form, templates or a note in the knowledge base.

Finally, the administrator links the automation team with infrastructure: storage capacity, backups, monitoring and availability. This prevents situations where the business wants to expand the system but it "lags" due to resource limits or hidden configuration errors.

How to start a competency center: a 30-day plan

Launching a competency center is best done as a short one-month project. The goal is not to write thick regulations but to establish a rhythm: requests arrive, decisions are made quickly, and changes are released regularly.

30-day plan

• Days 1–5: appoint a product owner and set 3–5 quarterly goals (for example, reduce approval time, remove manual input, lower error rates).
• Days 6–10: document 2–3 most painful current processes and mark bottlenecks. Collect a list of ideas and prioritize.
• Days 11–15: set up a single intake for requests and acceptance criteria for changes. Decide who confirms value, who checks requirements and who deploys changes.
• Days 16–25: run a pilot improvement cycle. Take 1–2 small changes and complete them end-to-end.
• Days 26–30: fix minimum rules, metrics and a release calendar so work continues after initial success.

Avoid trying to "digitize everything" at once. Choose one process where the effect will be clear and visible.

How to know you've really started

A good sign is a repeatable cycle: a weekly request review and releases every 2–4 weeks.

At the beginning, three metrics are enough: how many requests arrived, how many were completed on time, and the effect of 1–2 key improvements (time saved, errors reduced, cost). This builds trust and helps the system evolve rather than stall.

Working practices to keep the system evolving regularly

Automation only "lives" when it has a clear rhythm from request to release. The competency center's job is to make that rhythm a habit.

Single work queue: requests don't get lost

All ideas, problems and improvements should go to one place — a common backlog. It doesn't matter whether the request came from accounting, security or IT. What matters is that it doesn't disappear into a conversation.

The backlog needs an owner (usually the product owner), and each entry should include at least: short description, initiator, expected outcome and an example of how success will be measured. This protects against vague tasks like "make it work properly."

One version of truth for data

The system degrades quickly if everyone maintains reference data and formats differently. A simple rule: a specific role (often the analyst together with the business data owner) is responsible for key reference data and filling rules, while the administrator enforces technical constraints and access.

If departments spell counterparty names or request statuses differently, reports will diverge. It's easier to agree on a format once and enforce it in the system than to endlessly clean exports later.

Releases: predictable and safe

Regular small releases are better than rare large ones. Before deployment, follow a minimal set of steps: test in a staging environment, agree on a deployment window and send a short note to users about what changed and where to report issues.

Keep the checklist short: what we change and why, who checked and by which scenarios, when we enable it, what risks exist, and where to get support.

Priorities without disputes: value and effort

When requests are many, conflicts are inevitable. Simplify prioritization by scoring tasks on two axes: value (impact, risks, time savings) and effort (work size, dependencies). Focus first on "high value, low effort" and honestly defer "low value, high effort."

Documents that actually help

Documentation should aid work. Usually three items suffice: short data rules, descriptions of key processes at the level of steps and roles, and a release log (what changed and why). Add other documents only when a real need arises.

Common mistakes and traps when organizing the center

A competency center can look good on a diagram but stop working if roles are only formal. The main sign of trouble: tasks pile up, decisions are made "through acquaintances," and the system doesn't change for months.

Common traps:

• Roles on paper. People are assigned but have no time, no authority to say "no," and no access to process owners.
• Customization for its own sake. Small tweaks are made to suit individual teams, maintenance costs rise, and no one measures the benefits.
• Changes pushed directly to production. This almost guarantees downtime and distrust. Always have at least: a test environment, a short verification scenario, a rollback plan and a change log.
• No training and support. Without short instructions users revert to workarounds: spreadsheets, notebooks, messengers. Eventually no one knows the single source of truth.
• Administrator becomes a dispatcher. Their role should be owner of stability: access, security, integrations, standard incidents and release quality.

If you implement solutions with an integrator (for example, GSE.kz), agree in advance which areas remain with your team and which belong to the vendor. That prevents blurred responsibility and speeds up changes.

Quick check: 10 questions to see if the center works

If the competency center is alive, answers to these questions should be obvious without long calls or hunting for stakeholders. If you can't answer half of them clearly, the system will likely start to struggle.

1. Is there one person accountable for the product and final priorities?
2. Is there a single intake for requests and visible statuses: accepted, analyzing, in work, done?
3. Is there a clear evaluation order: what we do first and why?
4. Is there a delivery rhythm: small improvements at least every 2–4 weeks?
5. Is there minimal testing before release?
6. Is it clear who issues access, by what rules, and where this is recorded?
7. Is there an owner for key reference data who monitors quality?
8. Is there a knowledge base with short instructions and common errors, and is it updated?
9. Are there metrics: how many requests closed, how many in progress, how many overdue and why?
10. Is there a regular problem review (30 minutes weekly) where decisions are recorded and followed through?

A good sign: you can answer each question with one sentence and show where it is visible in operations.

Practical example: how to revive a stalled system

A city hospital implemented an equipment request and tracking system. For the first months everything ran well: faults were logged, movements recorded, repair histories collected. Then improvements almost stopped. Users reverted to "faster in chat," and only some requests and incomplete cards remained in the system.

Problems accumulated unnoticed. Requests came through multiple channels, so priorities were set by whoever was loudest. Access was handed out "just in case," and someone could accidentally change reference data. Accounting, engineering and management reports began to diverge because data were entered inconsistently or retroactively.

The situation turned around when a competency center with roles and rules was established.

• A product owner from the hospital was appointed: they collect goals, decide priorities and accept results.
• An analyst described the process from request to closure and set unified rules for filling fields.
• An administrator cleaned up access: role-based permissions, no blanket admin rights, and a change log.
• Releases were scheduled every two weeks: a short list of improvements, testing and a brief user guide.
• Change requests were moved to a single channel with a simple form: "what's the problem," "for whom," "how to measure improvement."

Within 6–8 weeks visible effects appeared: fewer manual approvals for repairs and write-offs, clear statuses for each request, and stable reports on downtime and expenses. Managers could more easily spot bottlenecks, and engineers worked through a queue without losing requests.

When load increased (new branches and 24/7 services), they proactively addressed two topics: 24/7 support and infrastructure capacity. Duty rosters, incident procedures and capacity planning helped ensure the system didn't slow down during peak hours.

Next steps: lock roles and ensure sustainable development

To keep the competency center from relying on enthusiasm, assign responsibilities now. The simplest marker: every task has an owner, a deadline and a clear acceptance criterion.

You can start tomorrow with small steps, no major reforms:

• appoint a product owner, analyst and administrator (even at 20–40% of their time);
• collect the top 10 user pain points: what prevents daily work;
• create a single backlog and a prioritization rule (value, risk, effort);
• adopt a short change cycle, e.g., a release every two weeks;
• set basic metrics: support response time, number of requests, share of tasks in progress.

Then honestly assess whether you can handle development internally. External help is useful when internal skills are lacking or concentrated in one person, systems are many and poorly integrated, or workload grows faster than the team.

External support can be targeted: process assessment, integration setup, definition of support and change rules, and training key users. The result should be not just configurations but knowledge transfer to your team.

If infrastructure is the bottleneck, act pragmatically: check performance, reliability, backups and monitoring. A common scenario: the system "lags" in the mornings, users move to Excel, and the backlog grows. Often a proper diagnosis and planned server upgrade are enough.

For large organizations in Kazakhstan it can be convenient to combine infrastructure and integration in one package. For example, GSE.kz as a vendor and system integrator supplies workstations and servers and performs implementation and support projects, which reduces risks when automation needs to evolve regularly and without downtime.