Как организация помнит: разбираем модель Уолша и Унгсона
Сотрудники сменились, документы переписали, а компания продолжает действовать по старым правилам. Разберём, где может сохраняться этот опыт, как проверить его полезность и какие вопросы стоит задать при устройстве памяти AI-агента — программы, которая использует модель и инструменты для выполнения задач.
В 1991 году Джеймс Уолш и Джерардо Ривера Унгсон опубликовали в Academy of Management Review статью Organizational Memory. Ниже — разбор её центральной модели и самостоятельный практический пример. Пример, рекомендации и сопоставление с AI-агентами разработаны для этого текста; их нет в оригинале.
Модель: опыт сохраняется в нескольких местах
Организационная память у авторов — сохранённая информация о прошлом организации, которую можно использовать в текущих решениях. Они выделяют три процесса: получение, сохранение и извлечение информации; пять внутренних носителей: людей, культуру, рабочие процессы, структуру ролей и физическую среду. Внешние архивы рассматриваются отдельно.
Извлечение бывает осознанным — когда ищут прежний случай — и автоматическим, через привычный порядок действий. Процедура способна сохранять ответ на проблему, утратив объяснение его появления. Даже воспоминания людей и общая история могут искажать причины решения.
Память помогает принимать и исполнять решения, но подходящий когда-то ответ может оказаться ошибочным сегодня. Выборочное сохранение и предъявление прошлого также может укреплять власть отдельных участников. Замена руководителя затрагивает лишь часть носителей: прежние способы работы могут продолжить действовать через остальные.
Это теоретическая модель с исследовательскими предположениями, а не экспериментальная проверка готового метода управления. Определение и носители разобраны на с. 61–68, извлечение — на с. 69–70, польза и ошибки применения — на с. 73–77 оригинала.
Одна скидка и пять способов помнить
Представим вымышленную торговую компанию. Во время кассового разрыва директор ввёл правило: любую скидку больше 10% нужно согласовывать с ним. Это было временное ограничение. Через два года финансовое положение изменилось, директор ушёл, но согласование осталось.
Разложим этот случай по пяти носителям модели. Названия взяты у авторов, ситуации в таблице придуманы для нашего примера.
| Носитель | Как он выглядит в этой компании | Что проверить при изменении правила |
|---|---|---|
| Люди | Старший менеджер помнит кассовый разрыв и объясняет новичкам, откуда взялось согласование | Остались ли участники решения; совпадают ли их воспоминания с записями того времени |
| Культура | В команде повторяют: «Большую скидку без директора давать опасно» | Воспринимают ли сотрудники новое полномочие как разрешённое действие или всё ещё боятся наказания |
| Рабочие процессы | Система продаж блокирует отправку предложения, пока директор не нажмёт кнопку | Изменены ли маршрут, форма и автоматическая проверка |
| Структура ролей | Право окончательного согласования закреплено за должностью директора | Кто теперь вправе решать и за что отвечает |
| Физическая среда | Рабочие места и лоток с бумажными заявками устроены вокруг личного визита к директору | Не возвращает ли организация рабочего места старую последовательность действий |
В статье третий носитель называется transformations: способы превращения входов в результаты. Здесь его представляет процесс подготовки коммерческого предложения. Пятый — ecology: физическое устройство места работы. Экран системы продаж в нашей таблице относится к процессу, а не автоматически к физической среде.
Допустим, новый директор убрал старую инструкцию из базы знаний. Менеджер всё равно не может отправить предложение: мешает проверка в системе. Разработчик убрал проверку — менеджер продолжает писать директору, потому что боится отвечать за скидку. Директор объявил о самостоятельности — должностные обязанности по-прежнему требуют согласования.
В этой условной истории последовательно меняли разные части одной практики. Поэтому проверка изменения должна доходить до реального действия: способен ли менеджер провести допустимую сделку по новому порядку, понимает ли свои полномочия и получает ли ожидаемый результат.
Как сохранить причину, а не только команду
Для этого примера полезнее была бы запись, в которой ограничение связано с исходной ситуацией. Ниже — мой рабочий вариант такой записи. Это предложение по организации знаний, а не шаблон из статьи 1991 года.
| Поле | Условная запись |
|---|---|
| Решение | Скидки больше 10% согласовывает директор |
| Причина | На момент решения не хватает оборотных средств |
| Область действия | Новые сделки определённого подразделения; действующие договоры рассматриваются отдельно |
| Основание | Датированный финансовый расчёт и запись принятого решения |
| Условие пересмотра | Финансовый владелец подтверждает изменение исходных условий |
| Кто вправе изменить | Назначенный ответственный за коммерческие полномочия |
| Где решение действует | Инструкция, роли в системе продаж, маршрут согласования, обучение сотрудников |
| Текущее состояние | Действует, пересмотрено или заменено; ссылка на новую редакцию |
Смысл такой формы — сделать правило проверяемым. Запись о прошлом отвечает, почему ограничение появилось; действующая редакция отвечает, что делать сейчас. При пересмотре старая запись остаётся свидетельством прежнего решения, а новая задаёт текущий порядок.
Одной даты обновления недостаточно. Документ мог быть отредактирован вчера ради опечатки. Для проверки применимости нужны условия: к каким сделкам относится правило, что изменилось и кто подтвердил изменение.
В маленькой команде вся запись может занимать один абзац. Поля полезны лишь настолько, насколько помогают восстановить решение и проверить действие; заполнять их ради полноты формы незачем.
Почему поиск ответа ещё не завершает работу
Теперь представим, что менеджер нашёл прошлогодний пример: директор разрешил похожему клиенту скидку 15%. Можно ли повторить её сегодня?
В нашем примере это пока неизвестно. Возможно, в прошлой сделке была предоплата, другой состав поставки или отдельное решение по клиенту. Наличие похожего прецедента даёт направление проверки, но само по себе не устанавливает полномочие.
Я бы разделил действия сотрудника так:
- Найти прошлое решение и первичное основание.
- Выяснить, какие обстоятельства определяли выбор.
- Сопоставить их с текущей сделкой.
- Проверить действующий порядок полномочий.
- Зафиксировать новое решение, если ситуация требует отступления.
Для обычной сделки, которая целиком укладывается в действующие правила, повторять всё исследование не нужно. Такая проверка особенно полезна при исключении, противоречии или изменении условий. Иначе мы просто заменим лишнее согласование лишней аналитической работой.
Чья версия прошлого становится рабочей
Добавим к примеру конфликт интересов. Руководитель настаивает на личном согласовании всех скидок и показывает команде только истории неудачных самостоятельных сделок. Удачные сделки в обсуждение не попадают.
Проверить отдельные предъявленные случаи недостаточно: каждый из них может быть правдивым. Нужно ещё понять, по какому принципу отобрали примеры. Для нашего разбора это различие между точностью записи и полнотой основания для решения.
Практический вопрос здесь звучит так: «Какие случаи могли бы опровергнуть предложенное объяснение?» Если рассматриваются только ошибки менеджеров, стоит отдельно посмотреть на сделки без согласования, которые прошли успешно, и на согласованные сделки, которые всё равно оказались неудачными. Это не доказывает, что контроль лишний; это делает проверку менее зависимой от одного рассказчика.
Что из этого можно перенести на AI-агента
Следующее сопоставление — моя проектная интерпретация. Статья 1991 года не исследует AI-агентов и не доказывает, что устройство человеческой организации можно перенести на них буквально.
Представим агента, который готовит коммерческие предложения. Он нашёл старый диалог с одобрением скидки и сохранил вывод: «Клиентам этого типа можно давать 15%». При следующем обращении агент использует эту запись.
Для проверки такого поведения я бы разделил три вопроса.
Что действительно произошло? Есть исходный диалог, в котором один человек одобрил одну сделку. Его следует уметь найти и прочитать в контексте.
Какой вывод сделал агент? Правило про всех клиентов — уже обобщение. Оно должно оставаться отличимым от первичного свидетельства. Без этой границы следующий запуск может принять интерпретацию за утверждённую политику.
Что разрешено делать сейчас? Даже верное описание прошлой сделки не выдаёт агенту полномочий согласовывать новую. Текущая инструкция, назначенная роль и ограничения инструментов должны определять допустимое действие.
Из этого примера получается конкретное требование к проектируемой памяти: у производной записи должны быть источник, область применимости и способ пересмотра. Если основание изменилось, нужно уметь найти зависящие от него выводы. Само наличие ссылки ещё не обеспечивает такой пересмотр — потребуется процесс или механизм, который действительно его выполняет.
Здесь нет необходимости превращать пять носителей Уолша и Унгсона в пять баз данных. Их схема помогает задать вопросы. Архитектуру системы придётся выбирать под конкретную задачу, а полезность — проверять по действиям агента.
Небольшая проверка вместо спора об архитектуре
Для нашего условного агента можно подготовить четыре сценария. Это проект теста, не результат проведённого эксперимента.
| Ситуация | Ожидаемое поведение |
|---|---|
| Повторяется типовая сделка в пределах действующего правила | Агент применяет текущий порядок без лишнего обращения к руководителю |
| Найден похожий случай, но изменились существенные условия | Агент замечает различие и запрашивает недостающее основание |
| Старое разрешение противоречит новой утверждённой инструкции | Агент объясняет противоречие и следует действующей инструкции в пределах полномочий |
| Из первичного источника отозвано основание для сохранённого обобщения | Система помечает зависимый вывод для пересмотра; агент не предъявляет его как проверенное правило |
Проверять стоит не только итоговый текст. Для каждого сценария нужны наблюдаемые свидетельства: какую запись нашли, какой источник открыли, почему признали его применимым и какое действие выполнили. Правильный ответ без возможности восстановить основание оставляет вопрос о повторяемости открытым.
Для человеческой команды аналогичная проба ещё проще: дать новому сотруднику одну обычную и одну изменившуюся ситуацию и посмотреть, как он находит правило и распознаёт исключение. Это может помочь обнаружить участок, требующий доработки: запись, доступ, обучение, полномочия или сам процесс.
С чего начать в своей системе
Выберите одно правило, которое команда регулярно применяет. Найдите решение, из которого оно выросло, и восстановите условия его появления. Затем проследите, где оно действует сегодня: в документах, привычках, полномочиях, интерфейсах и проверках.
После этого проведите одну пробу на изменившихся условиях. Может ли сотрудник или агент заметить, что прежний ответ перестал подходить, и дойти до человека, который вправе его пересмотреть? Ответ даст конкретную задачу по улучшению памяти — и способ проверить результат.
Термины
- Организационная память — в модели статьи информация о прошлом организации, которую можно использовать в нынешних решениях.
- Носитель памяти — место или способ сохранения опыта: например, воспоминание сотрудника или действующая процедура.
- Автоматическое извлечение — использование сохранённого способа действия без специального поиска исторического решения.
- AI-агент — в этом разборе программа, которая использует модель и инструменты для выполнения задачи в несколько шагов.
- Производная запись — вывод или обобщение, сделанное на основании других материалов.
Источник
James P. Walsh, Gerardo Rivera Ungson. Organizational Memory. Academy of Management Review, 1991, 16(1), 57–91. Карточка публикации в JSTOR, исходная статья в PDF.
Этот материал — самостоятельный разбор модели с условными примерами. Он не воспроизводит статью целиком и не заменяет чтение оригинала, в том числе его обзора литературы и обсуждения методов исследования.
Все материалы по теме: «Организационная и агентская память».
Хотите внедрить это у себя?
Помогаю командам перейти на агентную разработку: как советник, через обучение команды или внедрение изменений с проверкой эффекта по данным. Короткие заметки между статьями выходят в Telegram-канале.