Представьте: В пыльном архиве петербургской библиотеки лежит книга двадцатилетней давности. Название длинное и скучное — "Культура административной деятельности". Обложка серая. Автор загадочный — "Внутренний Предиктор СССР". Казалось бы, типичный артефакт нулевых, который интересен разве что историкам.
Но вот парадокс: эта книга описывает проблемы, с которыми каждый из нас сталкивается прямо сейчас, в 2026 году. Она объясняет, почему:
- Ваша новенькая CRM-система стоит миллионы, но менеджеры продолжают вести сделки в Excel
- Проект автоматизации затянулся на два года вместо шести месяцев
- Красивые дашборды показывают одни цифры, а реальность — совсем другие
- Половина компании не понимает, зачем вообще всё это внедрили
Давайте разберёмся, что такого написали в 2004-м, что работает лучше многих современных бизнес-книг.
Глава первая: Шесть шагов, которые меняют всё
Сцена: Понедельник, офис IT-интегратора
Максим, руководитель проектов по внедрению CRM, смотрит на монитор и не верит глазам. Очередной проект провалился. Заказчик — крупный дистрибьютор — отказывается платить за три месяца работы. Причина? "Система не работает так, как нам нужно".
— Я же делал всё по книжке! — Максим листает методичку вендора. — Установили, настроили, обучили. Что ещё нужно?
Его коллега Ирина, консультант с двадцатилетним стажем, усмехается:
— Макс, ты построил машину, но забыл спросить, куда они хотят ехать.
Она достаёт потрёпанную распечатку — ту самую книгу 2004 года.
— Смотри. Здесь написано, что любое управление — это не разовое действие, а цикл из шести шагов. Называется "полная функция управления".
Шаг 1: Выявление фактора среды
— Что вообще происходит? Какая проблема требует решения?
Шаг 2: Распознавание
— Как понять, что это именно ТА проблема, а не симптом чего-то другого?
Шаг 3: Целеполагание
— Чего именно мы хотим добиться? В цифрах, в датах, конкретно.
Шаг 4: Формирование концепции
— Как именно мы будем решать проблему? Какой план?
Шаг 5: Организация структуры
— Кто что делает? Какие инструменты используем?
Шаг 6: Контроль и коррекция
— Получилось ли? Что пошло не так? Возвращаемся к шагу 1.
— И что? — Максим пожимает плечами. — Это же очевидно.
— Вот именно, что очевидно. Но ты делал только шаг 5 — "организацию структуры". Установил CRM. А остальные пять шагов? — Ирина стучит пальцем по распечатке. — Ты понял их проблему? Поставил измеримые цели? Разработал концепцию, которая реально работает для их бизнеса?
Максим молчит. Действительно, он просто взял типовое решение и натянул его на клиента.
— Эта книга говорит: управление — это не линия, а круг. Ты прошёл линию от начала до конца и считаешь, что работа сделана. А надо было запустить круг, который крутится постоянно: проблема → понимание → цель → план → действие → проверка → новая проблема...
Современная ремарка: То, что описано в книге 2004 года, сегодня называют красивыми словами: PDCA (Plan-Do-Check-Act), Agile-спринты, цикл непрерывного совершенствования. Но суть одна — управление это не разовый марш-бросок, а бесконечный цикл.
Глава вторая: Карта сокровищ, нарисованная точками и стрелками
Сцена: Мастерская процессного аналитика
Дмитрий работает в компании, которая внедряет системы автоматизации. Его задача — понять, как устроена работа в компании клиента, и потом запрограммировать это в системе.
Обычно он делает так: приходит, разговаривает с людьми, рисует блок-схемы. Но почему-то реальная работа всегда отличается от его схем.
Однажды в библиотеке (да, он из тех странных людей, кто ещё ходит в библиотеки) он натыкается на ту самую книгу. И там — целая глава про сетевые модели.
Представьте карту метро. Есть станции (события, контрольные точки) и есть перегоны между ними (работы, процессы). Поезд не может "быть на 37% пути между станциями" — он либо доехал до станции, либо нет. Дискретно.
Книга говорит: любой бизнес-процесс — это сеть. Узлы — это моменты проверки: "Сделано? Да или нет?". Линии между узлами — это работа.
Пример из жизни CRM:
text[Подозрительный] → Позвонил? → [Лид] → Встретился? → [Возможность] → Договорился? → [Клиент]
На каждой стрелке — бинарный вопрос. Либо да, либо нет. Никаких "сделано на 50%". Либо ты встретился с клиентом, либо нет. Либо он подписал договор, либо нет.
Дмитрий начинает применять этот подход. И вдруг всё встаёт на свои места. Он больше не спрашивает менеджеров: "Насколько готова сделка?" Он спрашивает: "Вы прошли встречу с ЛПР? Да или нет? Получили письменное подтверждение бюджета? Да или нет?"
Сетевая модель — это не просто красивая картинка. Это инструкция для компьютера: в каком состоянии находится каждый процесс, что должно произойти для перехода в следующее состояние, кто за это отвечает.
Современная ремарка: То, что описано в книге как "сетевые модели", сегодня называется BPMN (Business Process Model and Notation). Это международный стандарт, который используют все крупные компании. Диаграммы BPMN — это и есть те самые карты с узлами и стрелками. А "дискретный контроль" — это конечные автоматы (Finite State Machines), на которых работают все workflow-системы от Salesforce до SAP.
Глава третья: Проклятие цифр, которым нельзя верить
Сцена: Кабинет директора по продажам
Анна Сергеевна смотрит на отчёт и хмурится. По данным CRM, её команда делает 200 звонков в день. Конверсия — 15%. План продаж перевыполнен на 12%.
Но реальность другая. Складские остатки растут. Дебиторка зашкаливает. Клиенты жалуются на сервис.
— Что здесь не так? — она вызывает руководителя IT-отдела.
Тот разводит руками:
— Система работает. Данные собирает. Цифры считает.
— Но цифры врут, Сергей Иванович. Или не врут, но... ничего не значат.
Она снова открывает ту самую книгу 2004 года. Там есть страшное слово — "метрологическая состоятельность". Звучит как заклинание, но смысл простой:
Показатель должен быть измеримым. Объективно. Точно. Воспроизводимо.
Анна Сергеевна начинает разбираться:
- "200 звонков в день" — а что считается звонком? Одна менеджер ставит задачу "позвонить" даже если не дозвонилась. Другая — только если поговорила. Третья забывает ставить вообще. Показатель субъективный.
- "Конверсия 15%" — от чего до чего? От лида до встречи? От встречи до сделки? Каждый менеджер считает по-своему. Показатель несопоставимый.
- "План перевыполнен на 12%" — а это продажи или отгрузки? Деньги на счёт пришли или просто договоры подписаны? Показатель неоднозначный.
Книга говорит жёстко: если показатель нельзя измерить объективно — им нельзя управлять. Это иллюзия контроля.
История из практики:
Компания внедрила "Показатель удовлетворённости клиентов". Каждый менеджер после сделки ставит оценку: "доволен" / "нейтрален" / "недоволен".
Через месяц выясняется: 95% клиентов "довольны". Но отток клиентов — 30% в год, один из худших в отрасли.
Что не так? Менеджер сам ставит оценку! Конечно, все "довольны" — кто же признается, что клиент ушёл недовольный?
Решение: Автоматическая отправка опроса клиенту. Стандартизированная шкала (NPS: "Порекомендуете ли нас?"). Анонимность. Вот это — метрологически состоятельный показатель.
Современная ремарка: Требование книги к "метрологической состоятельности" — это основа того, что сейчас называют Data-Driven Management (управление на основе данных). Появились целые фреймворки: SMART-цели (Specific, Measurable, Achievable, Relevant, Time-bound), OKR (Objectives and Key Results). Все они про одно: цель должна быть измеримой, иначе это не цель, а пожелание.
Глава четвёртая: Один в ответе за всех
Сцена: Совещание по проблемному проекту
Проект провалился. Сроки сорваны, бюджет превышен, заказчик недоволен.
Генеральный директор спрашивает:
— Кто виноват?
Долгая пауза. Потом начинается:
— Ну, мы же все делали...
— Это командная работа...
— Я свою часть сделал, а дальше...
— У нас же коллегиальное решение было...
Принцип размытой ответственности — болезнь всех корпораций. Когда "все виноваты" — значит, никто не виноват.
Книга 2004 года провозглашает жёстко: принцип персональной единоличной ответственности.
- За компанию в целом отвечает один человек — генеральный директор.
- За каждое направление — один директор.
- За каждый проект — один руководитель проекта.
- За каждую сделку в CRM — один менеджер.
Это не значит, что другие не участвуют. Это значит, что есть конечный адресат для вопроса "Кто отвечает?"
История из CRM:
Salesforce (самая популярная CRM в мире) устроена так: у каждой сделки есть поле "Owner" — владелец. Обязательное поле. Сделка без владельца — невозможна технически.
Почему? Потому что когда сделка зависает, нужно знать: кому звонить? На кого эскалировать? Кто придёт на ковёр к директору?
Может, над сделкой работает команда: менеджер, инженер, логист, юрист. Но owner один. Это его зона ответственности. Он координирует остальных.
Контраргумент: "А как же коллективная ответственность? Team spirit? Agile говорит про команду!"
Книга не против команд. Она за ясность. В Agile-команде есть Product Owner — один человек, который отвечает за продукт. Есть Scrum Master — один, кто отвечает за процесс. Есть разработчики — команда, но каждая задача (user story) имеет assignee — конкретного исполнителя.
Ясность ответственности = эффективность.
Глава пятая: Штампованные решения, которые реально работают
Сцена: Консалтинговая фирма
Виктория — консультант по автоматизации. Она заметила странную вещь: когда она внедряет CRM в ритейле, проблемы одни. Когда во фрэнчайзинге — другие. Когда в производстве — третьи. Но внутри одной отрасли — проблемы удивительно похожи.
Книга объясняет это через концепцию "профильной сетевой модели". У каждого типа бизнеса есть типовая структура работ. Свой "профиль".
Для дистрибьютора:
Лид → Квалификация → Коммерческое предложение → Согласование цены →
Договор → Заказ → Резерв на складе → Отгрузка → Доставка →
Подписание накладной → Оплата → Повторный заказ
Для IT-компании (проектные продажи):
Запрос → Анализ потребности → Презентация → Пилот-проект →
Коммерческое предложение → Согласование → Договор →
Предоплата → Реализация → Сдача-приёмка → Оплата → Поддержка
Видите? Совершенно разные профили. И если попытаться натянуть первую модель на второй бизнес — будет катастрофа.
Виктория начинает создавать библиотеку типовых решений по отраслям. Для каждой — свой набор процессов, свои стадии сделки, свои показатели эффективности, свои отчёты.
И вдруг — прорыв. Внедрения идут в 2 раза быстрее. Клиенты счастливы: "Как будто вы всю жизнь в нашей отрасли работали!"
А они и работали — через профильные модели предыдущих клиентов.
Современная ремарка: Крупные вендоры CRM уже поняли это. Salesforce сделал Financial Services Cloud, Health Cloud, Manufacturing Cloud — отраслевые облака с предустановленными процессами. Microsoft, SAP — то же самое. Это и есть коммерческая реализация "профильных моделей" из книги 2004 года.
Интермедия: А что там с искусственным интеллектом?
Самое интересное: книга 2004 года ничего не знает про современный ИИ. Там нет GPT, нет машинного обучения, нет автоматизации на основе нейросетей.
Но! Её фреймворк отлично работает с ИИ и для ИИ.
Представьте:
2004 год — полная функция управления:
- Человек выявляет проблему
- Человек распознаёт паттерн
- Человек ставит цель
- Человек придумывает решение
- Человек организует исполнение
- Человек контролирует результат
2026 год — полная функция управления с ИИ:
- ИИ мониторит 1000+ сигналов и выявляет проблемы
- ИИ анализирует исторические данные и находит паттерны
- Человек ставит стратегическую цель (с подсказками ИИ)
- ИИ генерирует несколько вариантов решения, человек выбирает
- Low-code платформа + RPA автоматизирует исполнение
- ИИ в реальном времени мониторит и автокорректирует
Видите? Структура осталась той же. Просто изменились исполнители.
История из 2026:
Компания внедрила Intelligent Process Automation (IPA) — гибрид RPA и ИИ.
Раньше: Менеджер получает лид → вручную оценивает его качество → решает, стоит ли звонить → звонит → вручную записывает результат в CRM.
Теперь: Лид попадает в систему → ИИ автоматически оценивает его (на основе 10 000 прошлых лидов) → присваивает score → автоматически назначает менеджеру с нужной специализацией → автоматически предлагает скрипт звонка → менеджер звонит → голосовой ИИ переводит разговор в текст и автоматически заполняет поля в CRM.
Человек делает только то, что реально требует человека — разговор с клиентом. Всё остальное — автоматика.
Но! Стратегию всё равно определяет человек: каких клиентов мы хотим? Какой ARPU нам нужен? Какую концепцию продаж применяем?
Книга 2004 года не устарела. Она просто нашла новых исполнителей.
Глава шестая: Почему всё равно не работает?
Максим из первой главы прочитал книгу. Выучил полную функцию управления. Нарисовал сетевые модели. Определил метрологически состоятельные показатели. Назначил ответственных.
Проект снова провалился.
— Почему?! — он почти плачет.
Ирина качает головой:
— Ты забыл про людей.
60% проектов автоматизации проваливаются не из-за технологий. Из-за людей.
Типичная история:
Компания покупает дорогую CRM. Внедряет. Обучает. Запускает. Проходит месяц — половина менеджеров продолжает работать в Excel и WhatsApp. CRM пустая.
— Почему не используете систему?
— Да там неудобно...
— Там долго...
— Да я по-старому быстрее...
— А зачем вообще это нужно? Мы и так хорошо продаём...
Это называется сопротивление изменениям. Естественная человеческая реакция: "Мы всегда так делали, зачем менять?"
Книга 2004 года про это почти не пишет. Это её главный пробел.
Но современная наука управления изменениями уже решила эту задачу. Есть модель ADKAR:
- Awareness — Осознание: люди должны понять, ЗАЧЕМ нужны изменения
- Desire — Желание: люди должны ЗАХОТЕТЬ меняться
- Knowledge — Знание: люди должны знать, КАК меняться
- Ability — Способность: люди должны УМЕТЬ меняться (обучение, практика)
- Reinforcement — Закрепление: изменения должны УДЕРЖАТЬСЯ (мотивация, контроль)
Решение Максима:
Вместо того, чтобы просто "внедрить CRM", он:
- Провёл встречу с менеджерами: показал, сколько времени они теряют на поиск информации в переписках и таблицах. Посчитали вместе: 2 часа в день на каждого. Осознание.
- Спросил: "Что бы вы хотели, чтобы система делала за вас?" Собрал пожелания. Вовлёк их в проектирование. Теперь это не "система навязанная сверху", а "система, которую мы сделали сами". Желание.
- Не просто провёл тренинг, а сделал "день в боевом режиме": каждый менеджер провёл реальную сделку через CRM, под присмотром наставника. Знание и способность.
- Геймификация: таблица лидеров по качеству заполнения CRM. Плюс бонус: кто качественно ведёт CRM, получает более тёплые лиды автоматически. Закрепление.
Через три месяца 95% сделок ведутся через CRM. Данные чистые. Отчёты достоверные. Продажи выросли на 23%.
Секрет: Технология — это 30% успеха. Люди — 70%.
Глава седьмая: Три способа склеить мир
Книга говорит красиво: производство любого товара — это коллективный труд. Телефон в вашем кармане — результат работы тысяч людей по всему миру: добыли редкоземельные металлы, сделали процессор, написали ПО, собрали, доставили, продали.
Но эти тысячи людей не работают в одной компании под одним начальником. Как же их координировать?
Книга описывает два способа:
- Иерархия — директивное управление внутри компании. Начальник сказал — подчинённый сделал.
- Рынок — ценовая координация между компаниями. Я плачу, ты производишь.
Рынок — это "клей", который соединяет независимые части производственной цепи.
Но в 2026 году появился третий способ, о котором книга не знала:
3. Платформы — цифровая координация через экосистемы.
Пример:
2004: Вы хотите купить билет на самолёт. Звоните в авиакомпанию (рынок). Или идёте к турагенту (посредник).
2026: Заходите на Авиасейлс. Там автоматически агрегированы предложения 500 авиакомпаний. Фильтры, сравнение, оплата, электронный билет. Платформа.
В бизнесе то же самое:
AWS Marketplace — платформа, где тысячи компаний продают облачные сервисы. Amazon координирует их всех: единый каталог, единая оплата, единые стандарты качества.
Salesforce AppExchange — магазин приложений для CRM. 5000+ приложений от разных разработчиков. Salesforce — платформа-оркестратор.
Что это значит для CRM?
Ваша CRM больше не может быть изолированным приложением. Она должна быть хабом экосистемы:
Поставщики ↔ Партнёры ↔ [CRM как оркестратор] ↔ Клиенты ↔ Дополнительные сервисы
Клиент заказал товар? CRM автоматически:
- Проверила наличие у поставщика (через API)
- Зарезервировала на складе партнёра (через интеграцию)
- Отправила курьерскую заявку (через систему доставки)
- Создала счёт в бухгалтерии (через интеграцию с ERP)
- Уведомила клиента (через Email/SMS/мессенджер)
Всё автоматически. Всё через платформу.
Книга 2004 года описала проблему — как координировать разрозненных участников. 2026 год дал решение — платформы с API.
Глава восьмая: Процессный детектив
Новая технология, о которой книга 2004 не могла знать: процессный майнинг (process mining).
Представьте:
Вы спрашиваете сотрудников: "Как у вас происходит обработка заказа?"
Они рассказывают: "Ну, сначала менеджер получает заявку, потом согласует с руководителем, потом передаёт на склад..."
Вы рисуете схему. Красиво. Логично.
А потом включаете процессный майнинг.
Это программа, которая анализирует реальные логи систем (ERP, CRM, email) и восстанавливает, что реально происходило.
И выясняется:
- 40% заказов вообще миновали согласование с руководителем
- 15% заказов попадали на склад, не пройдя через менеджера (клиенты писали напрямую кладовщику)
- Средний заказ проходил не 5 этапов, как в регламенте, а 12 (с возвратами, переделками, дублями)
- Узкое место — не склад, как все думали, а согласование цен: там заявки зависали на 3 дня
Процессный майнинг — это рентген вашего бизнеса.
Он показывает, что реально происходит, а не что должно происходить.
Кейс:
Крупный банк внедрил процессный майнинг для анализа выдачи кредитов. По регламенту — 7 дней. По факту — среднее время было 11 дней.
Почему? Оказалось, 60% заявок возвращались на доработку из-за неполного пакета документов. Клиент приносил бумаги, менеджер проверял (3 дня спустя), оказывалось — не хватает справки, клиент шёл за справкой (ещё 4 дня), приносил...
Решение: Автоматический чек-лист при приёме документов. "У вас должны быть: паспорт, ИНН, справка 2-НДФЛ...". Менеджер проверяет сразу на месте.
Результат: среднее время — 6 дней. Удовлетворённость клиентов выросла в 2 раза.
Связь с книгой:
Книга говорит: рисуйте сетевые модели процессов. Процессный майнинг отвечает: мы нарисуем их за вас, на основе реальных данных, а не субъективных мнений.
Финал: Что делать прямо сейчас
Вы прочитали про книгу 2004 года и современные технологии. Красиво, интересно. Но что с этим делать?
Если вы внедряете CRM/BPM:
Шаг 1: Пройдите полную функцию управления
Не начинайте с выбора системы! Начните с:
- Какая проблема? (не "нам нужна CRM", а "мы теряем клиентов, потому что...")
- Какая цель? (в цифрах: "снизить отток на 15% за полгода")
- Какая концепция? (как мы будем решать проблему? может, CRM не нужна вообще?)
Шаг 2: Нарисуйте сетевую модель
Ваша воронка продаж — это сеть с узлами. На каждом узле — бинарный вопрос: "Пройден этап? Да/нет". Пропишите критерии для каждого перехода.
Шаг 3: Определите метрологически состоятельные метрики
Каждый KPI должен отвечать на вопросы:
- Как измерить объективно?
- Кто будет измерять?
- Как часто?
- Где хранить?
- Кто несёт ответственность за достоверность?
Шаг 4: Назначьте единоличных ответственных
За каждую сделку — owner. За каждый процесс — process owner. За всю CRM — product owner.
Шаг 5: Найдите отраслевое решение
Не берите универсальную CRM. Ищите для своей индустрии. Или настраивайте под свою профильную модель.
Шаг 6: Управляйте изменениями
30-40% бюджета — на обучение, коммуникацию, мотивацию. Не экономьте на людях.
Если вы бизнес-интегратор:
Станьте не продавцом софта, а архитектором управления.
Используйте полную функцию управления как фреймворк:
- Выявление: процессный майнинг, интервью, аналитика
- Распознавание: бенчмаркинг, best practices отрасли
- Целеполагание: OKR, SMART-цели совместно с заказчиком
- Концепция: референсная архитектура, профильные модели
- Организация: конфигурация систем, интеграции
- Контроль: BI-дашборды, непрерывная оптимизация
Ваша ценность — не в том, что вы умеете настроить Salesforce. Ваша ценность — в том, что вы понимаете бизнес и можете выстроить управление.
Если вы просто читатель:
Возьмите одну идею из этой статьи и примените завтра:
- Нарисуйте свой рабочий процесс как сетевую модель с чёткими узлами
- Проверьте один KPI на метрологическую состоятельность: можно ли его измерить объективно?
- Примените цикл PDCA к одной проблеме: план → действие → проверка → корректировка
- Определите, за что конкретно вы лично отвечаете в проекте/компании
Одна маленькая перемена запустит цикл улучшений.
Послесловие: Мост через двадцать лет
Книга, написанная в 2004 году, когда не было iPhone, не было облачных технологий, не было машинного обучения... Предсказала принципы, по которым всё это будет работать.
Потому что она говорила не о технологиях. Она говорила о фундаментальных законах управления:
- Управление — это цикл, а не линия
- Процессы — это сети с дискретными состояниями
- Измерять можно только то, что измеримо
- Ответственность должна быть персонализирована
- У каждой индустрии свой профиль работы
Эти законы не устаревают. Меняются инструменты: от бумаги к Excel, от Excel к CRM, от CRM к AI-powered экосистемам. Но принципы — остаются.
2004 год дал нам карту. 2026 год — GPS-навигатор. Но маршрут остался тем же.
И если ваша CRM не работает, ваш проект автоматизации буксует, ваши отчёты не отражают реальность — вернитесь к основам.
Шесть шагов управления.
Сетевые модели.
Метрологическая состоятельность.
Персональная ответственность.
Иногда ответы на проблемы 2026 года лежат в книге 2004 года.
Просто нужно знать, где искать.
P.S.
Если после прочтения этой статьи вы пойдёте в библиотеку искать пыльную книгу "Культура административной деятельности" — автор статьи свою задачу выполнил.
Если вы просто по-новому посмотрите на свою CRM, на свои процессы, на свои метрики — автор тоже доволен.
А если вы запустите свой цикл непрерывного совершенствования, начав с шага 1 "Выявление фактора среды" — это будет лучшей наградой.
Удачи в автоматизации. И помните: технологии приходят и уходят, а управление остаётся.
Статья основана на анализе книги "Культура административной деятельности: Не обсуждаемые вопросы административной деятельности и менеджмента на примере организации управления предприятием по полной функции или Введение в «микроэкономику»" (СПб., 2004) и современных исследований в области BPM, CRM, IPA и управления изменениями 2025-2026 гг.
Помогаем компаниям внедрять CRM, ERP и прочие страшные аббревиатуры. www.konprav.ru Tелеграмм @ArchitectAPI