Process
Kā mēs izpētam procesu, pirms to automatizējam
Automatizācija, kas sākas bez skaidras izpratnes par procesu, parasti beidzas ar risinājumu, kas ātri jāpārtaisa vai kas vienkārši nestrādā praksē. Tāpēc, pirms piedāvājam risinājumu, mēs vispirms izprotam procesu — soli pa solim.
1. Vēlamais rezultāts un nepieciešamā informācija
Sākam ar jautājumu — kas tieši jums jāsasniedz, un kāda informācija šim rezultātam ir nepieciešama. No kādiem procesiem un sistēmām šī informācija nāk? Bez skaidra mērķa automatizācija viegli novirzās uz nevajadzīgām detaļām.
2. Prasību definēšana
Pirms ķeramies pie izpētes, pierakstām konkrētas prasības — ko risinājumam jāspēj izdarīt, un kādi ir tā robežnosacījumi.
3. Procesa izpēte
Šeit sākas galvenais darbs: nosakām atbildīgās personas, procesa posmus, nepieciešamos apstiprinājumus un katra iesaistītā cilvēka atbildību. To uzzīmējam kā swimlane diagrammu (Visio sauc to par „Cross-Functional Flowchart“) — horizontālas vai vertikālas joslas katrai lomai vai sistēmai, kas uzreiz parāda, kur process pāriet no viena cilvēka vai sistēmas pie nākamās.
4. Datu plūsma
Tad skatāmies, no kurienes dati rodas un kādā formātā tie pastāv — papīra dokuments, PDF, brīvs teksts vai strukturēti dati sistēmā. Formāts bieži nosaka, cik vienkārši vai sarežģīti būs process automatizēt.
5. Sarežģītu procesu vienkāršošana
Ja process ir sarežģīts — ar vairākiem atzariem un izņēmumiem — mēs to cenšamies linearizēt: pārvērst par vienu secīgu gaitu, pie katra soļa atzīmējot, kādas atkarības un kādas citas sistēmas tajā iesaistītas.
6. Esošo sistēmu izpēte
Tā kā klientam parasti jau ir piekļuve iesaistītajām sistēmām, mēs tajās ieskatāmies paši — bieži izrādās, ka vajadzīgā funkcionalitāte sistēmā jau pastāv, tikai netiek izmantota.
7. Savienojamības izvērtēšana
Pēdējais solis pirms risinājuma izvēles — izvērtējam, kā dati tehniski var pāriet no vienas sistēmas uz otru:
- API — labākais variants;
- automātiski ģenerēti e-pasti ar datiem — labs variants;
- eksports no sistēmas — labs variants (nozīmē, ka kaut kur būs manuāla ievade, bet tas ir pieņemami);
- datu izgūšana tieši no lietotāja saskarnes (GUI) — no tā izvairāmies, jo īstermiņā tas gandrīz vienmēr rada problēmas;
- ja nekas cits nestrādā — pēdējais variants ir manuāla kopēšana no sistēmas sarakstiem.
Kāpēc tas ir svarīgi
Kad šī aina ir skaidra, mums ir pilnīga izpratne, lai izvēlētos risinājumu, kas tiešām der — nevis vispārīgu „automatizācijas rīku“, kas izskatās labi demonstrācijā, bet nedarbojas ar jūsu reālajiem datiem un sistēmām.
Gribat, lai paskatāmies uz jūsu procesu tieši tā?
Bezmaksas procesa pārbaudeProcess
How we investigate a process before automating it
Automation that starts without a clear understanding of the process usually ends up needing a rebuild, or just doesn’t hold up in practice. So before we propose a solution, we understand the process first — step by step.
1. Desired outcome and the information needed
We start with the question: what exactly do you need to achieve, and what information does that outcome require? Which processes and systems does that information come from? Without a clear target, automation easily drifts toward unnecessary detail.
2. Defining requirements
Before investigating, we write down concrete requirements — what the solution needs to do, and its boundaries.
3. Process investigation
This is the core of the work: identifying who’s responsible, the process stages, the approvals needed, and each involved person’s accountability. We map it as a swimlane diagram (Visio calls it a “Cross-Functional Flowchart”) — horizontal or vertical lanes per role or system, which immediately shows where the process hands off from one person or system to the next.
4. Data flow
Next we look at where the data originates and in what format it exists — a paper document, a PDF, free text, or structured data in a system. Format often determines how simple or complex automating it will be.
5. Simplifying complex processes
If a process is complex — with multiple branches and exceptions — we try to linearize it: turn it into one sequential flow, noting at each step what dependencies exist and which other systems are involved.
6. Exploring existing systems
Since the client usually already has access to the systems involved, we explore them ourselves — it often turns out the functionality needed already exists in the system, just unused.
7. Assessing connectivity
The last step before choosing a solution — evaluating how data can technically move from one system to another:
- API — the best option;
- automated emails with data — good;
- export from the system — good (means manual input somewhere, but that’s acceptable);
- pulling data directly from the user interface (GUI) — we avoid this, since it almost always causes problems short-term;
- if nothing else works — the last resort is manual copying from system lists.
Why this matters
Once this picture is clear, we have a full understanding to choose a solution that actually fits — not a generic “automation tool” that looks good in a demo but doesn’t work with your real data and systems.
Want us to look at your process this way?
Free process checkПроцесс
Как мы изучаем процесс перед его автоматизацией
Автоматизация, которая начинается без чёткого понимания процесса, обычно заканчивается тем, что решение приходится переделывать — или оно просто не работает на практике. Поэтому прежде чем предложить решение, мы сначала разбираемся в процессе — шаг за шагом.
1. Желаемый результат и необходимая информация
Начинаем с вопроса: чего именно нужно достичь, и какая информация для этого результата требуется. Из каких процессов и систем приходит эта информация? Без чёткой цели автоматизация легко уходит в ненужные детали.
2. Определение требований
Перед тем как приступить к изучению, фиксируем конкретные требования — что решение должно уметь делать и каковы его границы.
3. Изучение процесса
Здесь начинается основная работа: определяем ответственных лиц, этапы процесса, необходимые согласования и зону ответственности каждого участника. Рисуем это как диаграмму дорожек (swimlane diagram, в Visio — «Cross-Functional Flowchart») — горизонтальные или вертикальные полосы для каждой роли или системы, которые сразу показывают, где процесс переходит от одного человека или системы к следующему.
4. Поток данных
Затем смотрим, откуда берутся данные и в каком формате они существуют — бумажный документ, PDF, свободный текст или структурированные данные в системе. Формат часто определяет, насколько просто или сложно будет автоматизировать процесс.
5. Упрощение сложных процессов
Если процесс сложный — с множеством ветвлений и исключений — мы стараемся его линеаризовать: превратить в одну последовательную цепочку, отмечая на каждом шаге, какие есть зависимости и какие другие системы задействованы.
6. Изучение существующих систем
Поскольку у клиента обычно уже есть доступ к задействованным системам, мы изучаем их сами — часто оказывается, что нужная функциональность в системе уже существует, просто не используется.
7. Оценка связности систем
Последний шаг перед выбором решения — оцениваем, как данные технически могут переходить из одной системы в другую:
- API — лучший вариант;
- автоматически формируемые письма с данными — хороший вариант;
- экспорт из системы — хороший вариант (означает, что где-то будет ручной ввод, но это приемлемо);
- извлечение данных напрямую из интерфейса пользователя (GUI) — этого избегаем, так как в краткосрочной перспективе это почти всегда создаёт проблемы;
- если ничего другого не работает — последний вариант — это ручное копирование из списков системы.
Почему это важно
Когда эта картина ясна, у нас есть полное понимание, чтобы выбрать решение, которое действительно подходит — а не общий «инструмент автоматизации», который хорошо смотрится на демонстрации, но не работает с вашими реальными данными и системами.
Хотите, чтобы мы так же посмотрели на ваш процесс?
Бесплатная проверка процесса