The post has been translated automatically. Original language: Russian
The product's history answers the question of how it all came about. The data card responds to another one: what happens right now when a person clicks a button, writes to support, or connects a new service.
In the first article of this series, I wrote about the moment when the product continues to work, and knowledge about the system around it no longer fits in the head of the team. In the following text, we reconstructed the history of the product's creation: what is in it, where did it come from, and how can we confirm the right to use it.
Now I want to look not back, but inside the working product.
Where does the data go after the form on the website? Who sees the user's message? Which systems do copies remain on? What changes if an employee uses an AI assistant or the team connects a new supplier?
From the outside, the path often looks like one screen and one button. Inside, it branches out quickly.
Start not with a list of data, but with an event.
When I started putting together a data management outline for a software project, the first difficulty wasn't the lack of the right column. Different people saw different parts of the same route.
The developer saw the database, integrations, and logs. The person who communicated with the clients saw the forms, mail, and correspondence. The manager remembered the work tables and external services. The documentary part had yet to be assembled.
Every description was true. None of them were complete maps.
For me, the work map begins precisely in this discrepancy: between the conceived architecture and the usual practice of the team.
Therefore, I would not start with the question "what data do we have?". He quickly leads to a list like "name, phone number, email, technical information." Such a list is useful, but it still does not show what the company is doing with this data.
The working question is different: what happens to the data inside one particular event?
For example:
- the user registers in the product;
- the client sends a request to support;
- the company accepts the payment;
- the candidate is responding to the vacancy;
- the team connects analytics, CRM or AI functions.
One event sets the border for the map. With it, you can already complete a real route from start to finish.
This is a first pass, not a complete registry of the entire company. His task is to assemble one verifiable route. When the method works on it, the map can be expanded to other significant processes.
Follow the route through the eyes of the data
Let's take the usual support message.
The user fills out the form. What can he contribute there? Just your name and email, or is it free text, a file, and a screenshot? Where does the form go? Is the application being created in the support system? Is a copy coming to the general mail? Does the issue get into the tracker? Can an employee forward it to the developer?
Then new questions appear.
Who has access to the application? Does the external provider of the support system see it? Where is the infrastructure located? Does the data remain in logs, backups, and uploads? What happens after the request is closed? Can a piece of correspondence end up in an AI tool if an employee asks for help with a response or error analysis?
One small process has already crossed the product interface, support, development, cloud infrastructure, vendor contracts, access rules, and people's work habits.
This is exactly what the map should show.
Show not only the systems, but also the copies.
The architectural diagram usually shows the main systems and integrations well. But data doesn't just live where it's supposed to live according to the scheme.
They can stay:
- in the email notification;
- in the issue comment;
- in the uploaded file;
- in the backup and event log;
- in a chat with a contractor;
- on the screenshot;
- in the history of the request to the AI tool.
Not every such copy means a violation. But an invisible copy cannot be consciously protected, restricted, or deleted.
Therefore, in the first pass, I would ask separately: where is the data stored by design and where does it remain in real work?
The difference between these two answers is often the most useful part of the map.
Write down the solutions next to the route
The data card should not attempt to provide a legal answer to every question immediately. But it should show where the answer already exists, and where the decision has not yet been made.
For each route, it is useful to see:
- why do we need the data?;
- whose data is this and whether there are any identifiers or information among them that require increased protection;
- who transmits them and from where;
- what kind of data is used;
- on what decision, contract, consent or other basis is the processing based;
- what systems and copies do they go through?;
- who gets access inside the company and how is it restricted;
- which external suppliers are involved;
- where exactly is the data stored and processed, including other countries;
- what determines the retention period and what triggers deletion;
- what organizational and technical measures protect them?;
- which document, setting, or recording confirms the agreement;
- who is responsible for the route and which question remains open.
In the first version, some of the cells will almost inevitably be empty. It is ok.
An honest "not found out" is more useful than a seemingly accurate answer that no one has checked.
At the research stage, such a cell shows the real work. But before launching a new process, questions about the purpose, basis, transfer and protection of data must turn into accepted decisions.
Assign a route owner and a map curator
One of the weak points of the card appears when it is given entirely to a lawyer, privacy or information security specialist.
These roles can assemble a structure, ask questions, and verify individual solutions. But they are not always the first to find out that a product has added a new field, support has started using another service, or the developers have enabled additional logging.
There is also a reverse problem. If you leave the map only to the owners of individual processes, the company will quickly have different formats, different description depths, and routes that no one has linked together.
Therefore, in the working model, responsibility is divided.
Each route has a process owner who sees the changes in the work itself. For registration, it can be a product owner. To support the function manager. To hire HR. For the infrastructure, the technical owner of the system.
The shared map also has a curator. The data governance, privacy, or other assigned role function supports the method, verifies the completeness and comparability of records, collects changes between processes, and connects the necessary assessment.
The goal is not to make the process owner a data governance specialist or transfer all responsibility to the supervisor. The task is to ensure that the route change does not remain invisible and gets into the general system.
Link the map to the points of change
The map becomes obsolete immediately after creation.
A new supplier, integration, a field in the form, a payment method, an AI tool, an access role, or a retention period change the route. If the update depends only on an annual review, the team will almost inevitably rebuild part of the picture.
Therefore, next to the map, you need a short list of events that return to it.:
- launching a new feature or client script;
- connecting or replacing an external service;
- changing the composition of the collected data;
- a new way of internal access or transfer;
- using AI for an existing process;
- changing the rules of storage, unloading or deletion;
- an incident or a customer's question that the card did not help answer.
The card does not become operational when the last line is filled in. It becomes operational when the team knows after which change it needs to be returned to.
First the table, then the diagram
The word "map" often makes you draw arrows between dozens of systems at once. For The critical flow diagram really helps. But you don't have to start with it.
By map here, I mean a small operational data flow map. This is not a technical data lineage, a corporate data catalog, or a ready-made registry of processing activities. But all these tools have the same factual basis.: what happens, where, with what data, and with the participation of whom.
On the first pass, one table, one event, and a conversation with two people who participate in the route from different sides are enough.
If their answers differ, the card has already brought benefits.
After that, you can add a second route, link the same systems, mark suppliers, and see recurring gaps. The diagram will appear later, when there is something to draw.
Checking for a single form
Open any form through which a person transmits your company's data: registration, a demo application, a support request, or a job response.
And try to go through it to the end.:
1. What data does the person enter himself and what does the system add automatically?
2. In which system does the first entry appear?
3. Who gets the notification and who can open the record later?
4. Which copies are created along the way?
5. Which external services are involved?
6. What should happen to the data when the goal ends?
7. Who will be the first to know if this route changes?
If you need to open three schemes to answer, ask one irreplaceable person and check old correspondence, this is not a failure.
This is the beginning of the work map.
История продукта отвечает на вопрос, как всё это появилось. Карта данных отвечает на другой: что происходит прямо сейчас, когда человек нажимает кнопку, пишет в поддержку или подключает новый сервис.
В первой статье этой серии я писала о моменте, когда продукт продолжает работать, а знания о системе вокруг него уже не помещаются в голове команды. В следующем тексте мы восстанавливали историю создания продукта: что в нём есть, откуда это появилось и чем можно подтвердить право использования.
Теперь хочется посмотреть не назад, а внутрь работающего продукта.
Куда попадают данные после формы на сайте? Кто видит обращение пользователя? В каких системах остаются копии? Что меняется, если сотрудник использует AI-ассистента или команда подключает нового поставщика?
Снаружи путь часто выглядит как один экран и одна кнопка. Внутри он быстро разветвляется.
Начните не со списка данных, а с события
Когда я начала собирать контур управления данными для software-проекта, первая сложность была не в отсутствии нужной колонки. Разные люди видели разные части одного и того же маршрута.
Разработчик видел базу данных, интеграции и логи. Человек, который общался с клиентами, видел формы, почту и переписку. Менеджер помнил рабочие таблицы и внешние сервисы. Документальную часть ещё предстояло собрать.
Каждое описание было правдой. Ни одно не было полной картой.
Для меня рабочая карта начинается именно в этом расхождении: между задуманной архитектурой и обычной практикой команды.
Поэтому я бы не начинала с вопроса «какие данные у нас есть?». Он быстро приводит к перечню вроде «имя, телефон, email, техническая информация». Такой список полезен, но он ещё не показывает, что компания с этими данными делает.
Рабочий вопрос звучит иначе: что происходит с данными внутри одного конкретного события?
Например:
- пользователь регистрируется в продукте;
- клиент отправляет запрос в поддержку;
- компания принимает оплату;
- кандидат откликается на вакансию;
- команда подключает аналитику, CRM или AI-функцию.
Одно событие задаёт карте границу. С ним уже можно пройти настоящий маршрут от начала до конца.
Это первый проход, а не полный реестр всей компании. Его задача в том, чтобы собрать один проверяемый маршрут. Когда метод заработает на нём, карту можно расширять на другие значимые процессы.
Пройдите маршрут глазами данных
Возьмём обычное обращение в поддержку.
Пользователь заполняет форму. Что он может туда внести? Только имя и email или ещё свободный текст, файл и снимок экрана? Куда уходит форма? Создаётся ли заявка в support-системе? Приходит ли копия на общую почту? Попадает ли задача в трекер? Может ли сотрудник переслать её разработчику?
Дальше появляются новые вопросы.
Кто имеет доступ к заявке? Видит ли её внешний поставщик support-системы? Где находится инфраструктура? Остаются ли данные в журналах, резервных копиях и выгрузках? Что происходит после закрытия обращения? Может ли фрагмент переписки оказаться в AI-инструменте, если сотрудник попросит помочь с ответом или анализом ошибки?
Один небольшой процесс уже пересёк интерфейс продукта, поддержку, разработку, облачную инфраструктуру, договоры с поставщиками, правила доступа и рабочие привычки людей.
Именно это должна показывать карта.
Покажите не только системы, но и копии
Архитектурная схема обычно хорошо показывает основные системы и интеграции. Но данные живут не только там, где им положено жить по схеме.
Они могут остаться:
- в уведомлении на почте;
- в комментарии к задаче;
- в выгруженном файле;
- в резервной копии и журнале событий;
- в чате с подрядчиком;
- на снимке экрана;
- в истории запроса к AI-инструменту.
Не каждая такая копия означает нарушение. Но невидимую копию невозможно осознанно защитить, ограничить или удалить.
Поэтому на первом проходе я бы отдельно спрашивала: где данные хранятся по замыслу и где они остаются в реальной работе?
Разница между этими двумя ответами часто и есть самая полезная часть карты.
Записывайте решения рядом с маршрутом
Карта данных не должна пытаться немедленно дать юридический ответ на каждый вопрос. Но она должна показать, где ответ уже есть, а где решение ещё не принято.
Для каждого маршрута полезно увидеть:
- зачем данные нужны;
- чьи это данные и есть ли среди них идентификаторы или сведения, требующие повышенной защиты;
- кто и откуда их передаёт;
- какие именно данные используются;
- на каком решении, договоре, согласии или другом основании держится обработка;
- через какие системы и копии они проходят;
- кто внутри компании получает доступ и как он ограничен;
- какие внешние поставщики участвуют;
- где именно данные хранятся и обрабатываются, включая другие страны;
- что определяет срок хранения и что запускает удаление;
- какие организационные и технические меры их защищают;
- какой документ, настройка или запись подтверждает договорённость;
- кто отвечает за маршрут и какой вопрос остаётся открытым.
В первой версии часть ячеек почти неизбежно будет пустой. Это нормально.
Честное «не выяснено» полезнее, чем точный на вид ответ, который никто не проверял.
На этапе исследования такая ячейка показывает настоящую работу. Но перед запуском нового процесса вопросы о цели, основании, передаче и защите данных должны превратиться в принятые решения.
Назначьте владельца маршруту и куратора карте
Одна из слабых точек карты появляется, когда её целиком отдают юристу, специалисту по privacy или информационной безопасности.
Эти роли могут собрать структуру, задать вопросы и проверить отдельные решения. Но они не всегда первыми узнают, что продукт добавил новое поле, support начал пользоваться другим сервисом или разработчики включили дополнительное логирование.
Есть и обратная проблема. Если оставить карту только владельцам отдельных процессов, у компании быстро появятся разные форматы, разная глубина описания и маршруты, которые никто не связал между собой.
Поэтому в рабочей модели ответственность разделена.
У каждого маршрута есть process owner, который видит изменения в самой работе. Для регистрации это может быть product owner. Для поддержки руководитель функции. Для найма HR. Для инфраструктуры технический владелец системы.
У общей карты тоже есть куратор. Функция data governance, privacy или другая назначенная роль поддерживает метод, проверяет полноту и сопоставимость записей, собирает изменения между процессами и подключает нужную оценку.
Задача не в том, чтобы сделать process owner специалистом по data governance или передать всю ответственность куратору. Задача в том, чтобы изменение маршрута не оставалось невидимым и попадало в общую систему.
Свяжите карту с моментами изменений
Карта начинает устаревать сразу после создания.
Новый поставщик, интеграция, поле в форме, способ оплаты, AI-инструмент, роль доступа или срок хранения меняют маршрут. Если обновление зависит только от ежегодной проверки, команда почти неизбежно будет восстанавливать часть картины заново.
Поэтому рядом с картой нужен короткий список событий, которые возвращают к ней:
- запуск новой функции или клиентского сценария;
- подключение или замена внешнего сервиса;
- изменение состава собираемых данных;
- новый способ внутреннего доступа или передачи;
- использование AI для уже существующего процесса;
- изменение правил хранения, выгрузки или удаления;
- инцидент или вопрос клиента, на который карта не помогла ответить.
Карта становится рабочей не тогда, когда заполнена последняя строка. Она становится рабочей, когда команда знает, после какого изменения к ней нужно вернуться.
Сначала таблица, потом диаграмма
Слово «карта» часто заставляет сразу рисовать стрелки между десятками систем. Для критичных потоков диаграмма действительно помогает. Но начинать с неё необязательно.
Здесь под картой я имею в виду небольшой operational data-flow map. Это не технический data lineage, не корпоративный data catalog и не готовый реестр processing activities. Но у всех этих инструментов одна и та же фактическая основа: что происходит, где, с какими данными и при участии кого.
На первом проходе достаточно одной таблицы, одного события и разговора с двумя людьми, которые участвуют в маршруте с разных сторон.
Если их ответы расходятся, карта уже принесла пользу.
После этого можно добавить второй маршрут, связать одинаковые системы, отметить поставщиков и увидеть повторяющиеся разрывы. Диаграмма появится позже, когда будет что рисовать.
Проверка на одну форму
Откройте любую форму, через которую человек передаёт данные вашей компании: регистрацию, заявку на демо, обращение в поддержку или отклик на вакансию.
И попробуйте пройти её до конца:
1. Какие данные человек вводит сам и что система добавляет автоматически?
2. В какой системе появляется первая запись?
3. Кто получает уведомление и кто может открыть запись позже?
4. Какие копии создаются по пути?
5. Какие внешние сервисы участвуют?
6. Что должно произойти с данными, когда цель закончится?
7. Кто узнает первым, если этот маршрут изменится?
Если для ответа нужно открыть три схемы, спросить одного незаменимого человека и проверить старую переписку, это не провал.
Это и есть начало рабочей карты.
Share
