The post has been translated automatically. Original language: Russian
The document can be written in a week. The mechanism becomes operational not at the moment of approval, but where a person makes a decision and either goes through it or bypasses it.
In the first article of this series, I promised to come back to one question.: how not to turn the system around the product into a document library that no one opens.
This text is about the moment when the mechanism has already been designed, described, and even agreed upon. But the team's work has remained the same.
It seems to me the most underrated part of the job. A good document does not change the behavior. To do this, the rule must appear at the right moment, withstand the first urgent case and leave a mark.
The gap is visible not in the document, but in the solution.
The finished document is easy to check for completeness. All sections are in place, the roles are named, the responsible ones are assigned, the scheme is drawn.
The document does not allow you to check if it is working.
The most honest place to check: a specific decision that someone made last week. A new supplier. Access to the database for the contractor. AI is a feature that has been enabled in the meeting service. The exception is for an urgent release. Additional field in the registration form.
Did this decision go through the designed mechanism? Did the person know that the mechanism existed? Did the mechanism have time to respond before the decision was already made?
When working with processes, I usually start with the gap between the stated rule and how the work actually works. A breakup rarely means that people are undisciplined. Much more often, it means that the mechanism was designed away from the place where the work takes place.
It seems useful to separate two things here. The designed system describes the order: roles, steps, criteria, and the entry form. A working system influences a real decision. Implementation lies in between, and it almost never comes down to sending out a document.
Put the mechanism where the decision is already being made.
The mechanism that lives in a separate document participates in its work only through human memory.
And decisions are not made in a document. They are accepted in a tracker task, in a pool request, in correspondence with a supplier, in the form of a counterparty's establishment, in a team chat, on a conference call, and in an invoice for a new service.
Therefore, the first question of the implementation is not "how to explain the rule?", but "where exactly will the person meet with him?".
The options are usually mundane:
- a field or a mandatory step in the form of establishing a new supplier;
- an item in the task template for a release or a new feature;
- the question is in the checklist before connecting the external service;
- required line in the contract or purchase request template;
- the reminder is in the channel where the decision is being discussed, not in the general;
- a record without which the application does not move on.
The difference between "everyone knows the rule" and "it's hard to get past the rule," and there's a difference between a beautiful scheme and a working mechanism.
At the same time, embeddedness does not mean that every step needs to be turned into a mandatory barrier. The barrier is justified where the error is expensive and difficult to undo. In other places, it is enough for the question to appear before your eyes in time.
Give the exception a specified path
Any rule sooner or later encounters a situation for which it was not intended.
The client requires integration by Friday. The supplier is the only one on the market. The team needs the data today, and the approval is scheduled for a week. The tool solves a problem that is simply not on the list of allowed tasks.
If such a situation does not have a prescribed path, it does not disappear. She goes out of sight.
This is exactly the mechanism that we discussed in the text about shadow AI. The employee does not sabotage the rules. He has a task, and he finds a route that allows him to solve it.
Therefore, the exception should be designed together with the main route.:
- who has the right to allow a deviation and to what extent;
- how long does he have to answer;
- what conditions are required even if excluded;
- what is recorded and where;
- when this exception will be returned.
The provided exclusion path preserves the team's speed and leaves the company with visibility. A recurring exception often turns out not to be a violation, but a message that the rule describes the work inaccurately.
Check if the mechanism keeps up with the work.
The process has a speed, and it either matches the rhythm of the work, or it doesn't.
If a decision is needed today, and approval takes two weeks, the mechanism does not lose because it is poorly written. He's losing out on time.
This should be measured honestly and using your own examples. How long has it been from question to answer in the last five cases? How many people did it take? How many times has the request been returned for clarification? How many decisions were made before the process had time to respond?
It often turns out that the mechanism does not need additional discipline. He needs a shorter route for typical cases and a more attentive route for rare and expensive ones.
A slow process does not protect the company. He pushes himself out of work.
Leave a trace that can be used to restore the solution.
A mechanism that leaves nothing behind cannot be confirmed or improved.
The footprint doesn't have to be heavy. Usually, a short record is enough: what decision was made, who made it, on what data, what conditions were set, what remained open, and when they will return to it.
The value of such a record becomes clear later. Six months later, no one remembers why the supplier was given extended access and whether it was a conscious decision or an accident. When a client questions, disputes, incidents, or transfers the process to another person, recording turns out to be the only way to distinguish the decision from the established habit.
And one more observation. If there is no trace, then after a year it is impossible to understand whether the rule worked or was simply circumvented. Both paintings look the same: there are no complaints.
Name who owns the mechanism when the enthusiasm ends.
The new order is usually based on a specific person to whom it is important. As long as this person is around, everything looks stable.
Then he goes on vacation, changes his role, or switches to a more urgent task. Two months later, it turns out that the registry has not been updated, and the approvals are happening again in private messages.
In the text about the data map, I suggested sharing responsibility: each route has a process owner who sees the change first, and the shared map has a curator who supports the method. For implementation, you need the same pair of roles, but with a different focus.
The process owner is responsible for making the mechanism work in real work. The supervisor is responsible for the mechanism itself: why it looks the way it does, what changes in it, and what signals come from the teams.
But the mechanism itself will not hold a role in the scheme. If the manager asks you to "skip it now, we'll do it later" in a personal message, the team quickly understands the real procedure. One such case is more instructive than ten newsletters with new regulations. Therefore, the exception must go through the same visible route, even if the decision is made by a person with more authority.
Both need time in their workload. An implementation that exists only as an adjunct to basic employment usually loses out to everything else.
Consider the implementation as a period, not a date.
The launch has a date. I don't have it.
After the announcement of the new order, there comes a period when the mechanism still requires attention: the first cases are dealt with manually, the wording is clarified, and there are situations that no one foresaw. This is a normal part of the job, not a sign of poor design.
Therefore, it is useful to keep a short list of events that are returned to the mechanism next to it. Such a list has already appeared twice in this series: next to the data card and next to the AI use cases registry. This is not a coincidence. Anything that needs to survive its own launch needs an excuse to return before the annual audit is triggered.
Here the list refers to the mechanism itself:
- a new type of customer, market or contract;
- change of instrument, supplier or tariff;
- changing the composition of data or the circle of people with access;
- the emergence of AI in a process that was previously completely human;
- an incident, complaint, or question that the mechanism did not help answer.;
- recurring exception;
- the departure of the person who kept part of the route.
And one feature that I find particularly useful. If no changes have been made to the mechanism in six months, I would not I was in a hurry to rejoice at his stability. First, I would check if they use it at all. The living order is changing because real work is beating against it all the time.
The professional framework also looks beyond the document.
The NIST AI Risk Management Framework speaks not just about the availability of policies and procedures, but about their effective implementation. The framework requires planning continuous monitoring and periodic review of the risk management process, defining roles, training people, and including change management in monitoring the AI system after launch. This is a voluntary framework, and its version 1.0 is currently being reviewed.
ISO/IEC 42001 describes an AI management system that needs to be installed, implemented, maintained, and continuously improved. Maintenance and improvement here are the same parts of the system as the initial design.
The UK government's AI Playbook recommends connecting assurance teams at an early stage of the project. He separately links the life cycle of an AI tool with its daily maintenance, updating, and safe decommissioning. This is a government guideline of one jurisdiction, not a universal corporate requirement.
None of these frameworks will tell the company what form to put the field in and how many hours to give for approval. But they all consider implementation, monitoring, and change to be part of the management system, rather than the work that begins after writing the documents.
The Kazakhstan framework does not finish launch management either
The current Law of the Republic of Kazakhstan "On Artificial Intelligence" requires that the owner, the owner and the user constantly monitor the system to the extent of their role at all stages of the life cycle. For owners and owners, risk management is defined as an ongoing process. Risks should be updated at least once a year, and if certain serious risks are identified, immediate action is required.
It is the construction that is important for the theme of this text. The law does not describe how a company can bring internal order to a working state, and does not issue a ready-made form. But he proceeds from the fact that responsibility is tied to the role, and working with risks does not end with the launch.
In other words, the law presupposes a living process. You'll still have to make it live inside the company yourself.
Checking for a single solution
Take one mechanism that you have already implemented: a vendor approval route, an AI use cases registry, a data map, an access rule, or a release order.
Find the last real solution that had to go through it.
And try to answer:
1. Did the decision go through the mechanism or past it?
2. At what point was the person supposed to meet him and did he meet him?
3. How long did the mechanism respond and did it have time to make a decision?
4. What is left written down and where does it lie?
5. Who would have known if the mechanism hadn't worked?
6. What has changed in the mechanism itself over the past six months?
If the answers are found quickly and the two people from different sides of the process match, the mechanism is alive.
If the decision has passed by, but formally everything has been observed, you do not have a discipline problem on your hands. You have an exact indication of the place where the system needs to be completed.
In the first article, I promised to return to how not to turn the system around the product into a document library. Now I would answer in short: every rule should have a place and a moment where it changes the decision.
If there is no such moment, the document may be flawless. There is no system anyway.
Документ можно написать за неделю. Механизм становится рабочим не в момент утверждения, а там, где человек принимает решение и либо проходит через него, либо обходит.
В первой статье этой серии я обещала вернуться к одному вопросу: как не превратить систему вокруг продукта в библиотеку документов, которую никто не открывает.
Этот текст о моменте, когда механизм уже спроектирован, описан и даже согласован. А работа команды осталась прежней.
Мне это кажется самой недооценённой частью работы. Хороший документ ещё не меняет поведение. Для этого правило должно появиться в нужный момент, выдержать первый срочный случай и оставить после себя след.
Разрыв виден не в документе, а в решении
Готовый документ легко проверить на полноту. Все разделы на месте, роли названы, ответственные назначены, схема нарисована.
Проверить, работает ли он, документ не позволяет.
Самое честное место проверки: конкретное решение, которое кто-то принял на прошлой неделе. Новый поставщик. Доступ к базе для подрядчика. AI-функция, которую включили в сервисе для встреч. Исключение для срочного релиза. Дополнительное поле в форме регистрации.
Прошло ли это решение через спроектированный механизм? Знал ли человек, что механизм существует? Успел ли механизм ответить до того, как решение уже приняли?
В работе с процессами я обычно начинаю именно с разрыва между заявленным правилом и тем, как работа устроена на самом деле. Разрыв редко означает, что люди недисциплинированны. Гораздо чаще он означает, что механизм спроектировали в стороне от того места, где работа происходит.
Здесь мне кажется полезным разделить две вещи. Спроектированная система описывает порядок: роли, шаги, критерии, форму записи. Работающая система влияет на реальное решение. Между ними лежит внедрение, и оно почти никогда не сводится к рассылке документа.
Поставьте механизм туда, где решение уже принимается
Механизм, который живёт отдельным документом, участвует в работе только через память человека.
А решения принимаются не в документе. Они принимаются в задаче трекера, в пул-реквесте, в переписке с поставщиком, в форме заведения контрагента, в чате команды, на созвоне, в счёте на оплату нового сервиса.
Поэтому первый вопрос внедрения звучит не «как объяснить правило?», а «где именно человек с ним встретится?».
Варианты обычно приземлённые:
- поле или обязательный шаг в форме заведения нового поставщика;
- пункт в шаблоне задачи на релиз или на новую функцию;
- вопрос в чек-листе перед подключением внешнего сервиса;
- обязательная строка в шаблоне договора или заявки на закупку;
- напоминание в том канале, где обсуждается решение, а не в общем;
- запись, без которой заявка не двигается дальше.
Разница между «все знают правило» и «мимо правила трудно пройти» и есть разница между красивой схемой и работающим механизмом.
При этом встроенность не означает, что каждый шаг нужно превращать в обязательный барьер. Барьер оправдан там, где ошибка дорого стоит и её трудно откатить. В остальных местах достаточно, чтобы вопрос вовремя появился перед глазами.
Дайте исключению предусмотренный путь
Любое правило рано или поздно встречает ситуацию, для которой оно не предназначалось.
Клиент требует интеграцию к пятнице. Поставщик единственный на рынке. Данные нужны команде сегодня, а согласование рассчитано на неделю. Инструмент решает задачу, которой в списке разрешённых просто нет.
Если у такой ситуации нет предусмотренного пути, она не исчезает. Она уходит из поля зрения.
Это ровно тот механизм, который мы разбирали в тексте про shadow AI. Сотрудник не саботирует правила. У него есть задача, и он находит маршрут, который позволяет её решить.
Поэтому исключение стоит проектировать вместе с основным маршрутом:
- кто вправе разрешить отклонение и в каком объёме;
- за какое время он обязан ответить;
- какие условия обязательны даже при исключении;
- что записывается и где;
- когда к этому исключению вернутся.
Предусмотренный путь для исключения сохраняет скорость команды и оставляет компании видимость. Повторяющееся исключение часто оказывается не нарушением, а сообщением о том, что правило описывает работу неточно.
Проверьте, успевает ли механизм за работой
У процесса есть скорость, и она либо совпадает с ритмом работы, либо нет.
Если решение нужно сегодня, а согласование занимает две недели, механизм проигрывает не потому, что он плохо написан. Он проигрывает по времени.
Это стоит измерять честно и на своих же примерах. Сколько прошло от вопроса до ответа в последних пяти случаях? Сколько людей потребовалось? Сколько раз заявка возвращалась за уточнением? Сколько решений было принято до того, как процесс успел ответить?
Часто выясняется, что механизм не нуждается в дополнительной дисциплине. Ему нужен короткий путь для типовых случаев и более внимательный маршрут для редких и дорогих.
Медленный процесс не защищает компанию. Он вытесняет себя из работы.
Оставьте след, по которому решение можно восстановить
Механизм, после которого ничего не остаётся, невозможно ни подтвердить, ни улучшить.
След не обязан быть тяжёлым. Обычно достаточно короткой записи: какое решение приняли, кто его принял, на каких данных, какие условия поставили, что осталось открытым и когда к этому вернутся.
Ценность такой записи становится понятной позже. Через полгода никто не помнит, почему поставщику дали расширенный доступ и было ли это осознанным решением или случайностью. При вопросе клиента, споре, инциденте или передаче процесса другому человеку запись оказывается единственным способом отличить принятое решение от сложившейся привычки.
И ещё одно наблюдение. Если след не остаётся, то через год невозможно понять, работало правило или его просто обходили. Обе картины выглядят одинаково: жалоб нет.
Назовите, кто владеет механизмом, когда энтузиазм закончится
Новый порядок обычно держится на конкретном человеке, которому он важен. Пока этот человек рядом, всё выглядит устойчивым.
Затем он уходит в отпуск, меняет роль или переключается на более срочную задачу. Через два месяца оказывается, что реестр не обновляли, а согласования снова происходят в личных сообщениях.
В тексте про карту данных я предлагала разделять ответственность: у каждого маршрута есть владелец процесса, который первым видит изменение, а у общей карты есть куратор, который поддерживает метод. Для внедрения нужна та же пара ролей, но с другим акцентом.
Владелец процесса отвечает за то, чтобы механизм срабатывал в реальной работе. Куратор отвечает за сам механизм: почему он выглядит так, что в нём меняется, какие сигналы приходят от команд.
Но роль в схеме сама по себе механизм не удержит. Если руководитель просит «сейчас пропустить, потом оформим» в личном сообщении, команда быстро понимает настоящий порядок. Один такой случай обучает сильнее, чем десять рассылок с новым регламентом. Поэтому исключение должно проходить через тот же видимый маршрут, даже если решение принимает человек с большими полномочиями.
И тому и другому нужно время в рабочей нагрузке. Внедрение, которое существует только как дополнение к основной занятости, обычно проигрывает всему остальному.
Считайте внедрение периодом, а не датой
У запуска есть дата. У внедрения её нет.
После объявления нового порядка наступает период, когда механизм ещё требует внимания: первые случаи разбираются вручную, формулировки уточняются, находятся ситуации, которых никто не предвидел. Это нормальная часть работы, а не признак плохого проектирования.
Поэтому рядом с механизмом полезно держать короткий список событий, которые к нему возвращают. Такой список уже дважды появлялся в этой серии: рядом с картой данных и рядом с реестром AI use cases. Это не совпадение. Всё, что должно пережить собственный запуск, нуждается в поводах вернуться раньше, чем сработает годовая проверка.
Здесь список относится к самому механизму:
- новый тип клиента, рынка или контракта;
- смена инструмента, поставщика или тарифа;
- изменение состава данных или круга людей с доступом;
- появление AI в процессе, который раньше был полностью человеческим;
- инцидент, жалоба или вопрос, на который механизм не помог ответить;
- повторяющееся исключение;
- уход человека, на котором держалась часть маршрута.
И один признак, который я считаю особенно полезным. Если за полгода в механизм не внесли ни одного изменения, я бы не спешила радоваться его стабильности. Сначала проверила бы, пользуются ли им вообще. Живой порядок меняется, потому что о него всё время бьётся реальная работа.
Профессиональные рамки тоже смотрят дальше документа
NIST AI Risk Management Framework говорит не просто о наличии политик и процедур, а об их эффективном внедрении. Рамка требует планировать постоянный мониторинг и периодический пересмотр процесса управления рисками, определять роли, обучать людей и включать change management в наблюдение за AI-системой после запуска. Это добровольная рамка, и её версия 1.0 сейчас пересматривается.
ISO/IEC 42001 описывает систему менеджмента AI, которую нужно установить, внедрить, поддерживать и постоянно улучшать. Поддержание и улучшение здесь такие же части системы, как первоначальное проектирование.
AI Playbook правительства Великобритании рекомендует подключать assurance-команды на раннем этапе проекта. Он отдельно связывает жизненный цикл AI-инструмента с его повседневным сопровождением, обновлением и безопасным выводом из эксплуатации. Это государственное руководство одной юрисдикции, а не универсальное корпоративное требование.
Ни одна из этих рамок не подскажет компании, в какую форму поставить поле и сколько часов дать на согласование. Но все они считают внедрение, мониторинг и изменение частью системы управления, а не работой, которая начинается после написания документов.
Казахстанская рамка тоже не заканчивает управление запуском
Действующий Закон Республики Казахстан «Об искусственном интеллекте» требует, чтобы собственник, владелец и пользователь постоянно контролировали систему в объёме своей роли на всех этапах жизненного цикла. Для собственников и владельцев управление рисками определено как непрерывный процесс. Риски должны обновляться не реже одного раза в год, а при выявлении отдельных серьёзных рисков требуются немедленные меры.
Для темы этого текста важна именно конструкция. Закон не описывает, как компании довести внутренний порядок до рабочего состояния, и не выдаёт готовой формы. Но он исходит из того, что ответственность привязана к роли, а работа с рисками не заканчивается вместе с запуском.
Иными словами, закон предполагает живой процесс. Сделать его живым внутри компании всё равно придётся самостоятельно.
Проверка на одно решение
Возьмите один механизм, который вы уже внедрили: маршрут согласования поставщика, реестр AI use cases, карту данных, правило доступа или порядок релиза.
Найдите последнее реальное решение, которое должно было через него пройти.
И попробуйте ответить:
1. Прошло ли решение через механизм или мимо него?
2. В какой момент человек должен был его встретить и встретил ли?
3. Сколько времени механизм отвечал и успел ли он к решению?
4. Что осталось записано и где это лежит?
5. Кто узнал бы, если бы механизм не сработал?
6. Что изменилось в самом механизме за последние полгода?
Если ответы находятся быстро и совпадают у двух человек с разных сторон процесса, механизм живой.
Если решение прошло мимо, а формально всё соблюдено, у вас на руках не проблема дисциплины. У вас точное указание на то место, где систему нужно достроить.
В первой статье я обещала вернуться к тому, как не превратить систему вокруг продукта в библиотеку документов. Теперь я бы ответила короче: у каждого правила должно быть место и момент, где оно меняет решение.
Если такого момента нет, документ может быть безупречным. Системы всё равно нет.
Share
