Машина управления: у работы должен быть следующий шаг

Заказ остаётся одним заказом

Представим, что человек прислал рисунок мебели для маленькой мастерской. Это демонстрационный сценарий. Сначала нужно понять задачу, затем согласовать решение, подготовить производство, изготовить и передать вещь. При этом меняются исполнители и виды работы, но сам замысел не должен начинаться заново на каждом этапе.

В нашей CRM заказ проходит общий путь. Доска показывает, где находятся сделки. Список помогает сравнить их. Карточка собирает контекст конкретной работы. Это разные представления одного состояния, поэтому переход от разговора к производству не должен требовать создания несвязанных копий.

Сообщения, задачи, производственные материалы и финансовые события связываются с работой, к которой относятся. Человеку легче восстановить не только «какой сейчас этап», но и «что произошло и почему». История нужна для продолжения дела.

Что такое сделка и как читать её карточку

Сделка — отдельное дело с конкретным результатом: изготовить вещь для покупателя, выполнить заказ или получить поставку. Контрагент отвечает на вопрос «с кем работаем», сделка — «что делаем вместе». У одного покупателя могут быть разные заказы; одна закупка может помогать исполнить производственную потребность.

Карточка объединяет несколько уровней. В шапке — номер, название, текущий этап, контрагент и ответственный. Информаторы показывают время на этапе, цену, поступления, расход и бронь ресурсов, а также продвижение изготовления. Рядом с производственными комплектами открываются документы и 3D-модель. Центральная лента хранит общение и факты, панель задач — конкретные действия команды.

На десктопе лента и задачи видны рядом: можно читать обсуждение и сразу понимать, что поручено. На телефоне эти же данные подаются компактнее. Скриншот после вступления показывает настоящий интерфейс карточки; частные имена, суммы и реквизиты размыты.

Этапы: от обращения до результата

Этап — положение дела в процессе, а задача — действие, которое помогает его продолжить. Создание задачи само по себе не означает перевод сделки на другой этап.

• Продажи: «Новые» → «Расчёт» → «Предложение выставлено» → подготовка документов → ожидание оплаты → «Оплачено».
• Производство: «Входящие производства» → «Раскрой» → «Сборка и отделка» → «Передача».
• Контроль и завершение: контроль, документы и акты → публикация истории → «Готово».
• Поставка: «Новые» → «В работе» → «Поставка обработана».
• Другие исходы: реактивация, нереализованная работа и спам имеют отдельные состояния.

Это карта основных путей текущей конфигурации. Допустимые возвраты и переходы определяются правилами: например, предложение может потребовать нового расчёта. Поэтому процесс умеет отражать реальные уточнения, сохраняя историю движения.

Покупатель, поставщик, сервис — разные роли общения

Покупатель обращается за результатом нашей работы. Поставщик предоставляет нужные ресурсы или услуги. Сервис — инфраструктурный контакт, чьи уведомления нужно сохранить без превращения каждого письма в новый заказ. Класс и настройки входящих помогают направлять переписку в подходящий процесс.

Задача «Закупка» связывает потребность исходного заказа с работой снабжения. Для неё можно выбрать существующую поставку или создать новую, а также оставить ручной контроль. Получается понятная связь: заказу нужен материал → сотрудник занимается закупкой → поставка проходит свои этапы. Участники видят собственную работу, сохраняя связь с общим результатом.

Импульс, ресурс, исполнитель, результат

Импульс — причина действовать: обращение, принятое решение, законченный предыдущий этап или обнаруженное отклонение. Ресурсы — время, знания, материал, оборудование и деньги. Исполнитель — человек, который берёт следующий шаг. Результат — наблюдаемое изменение, которое можно принять.

Например, «заняться проектом» слишком расплывчато. «Уточнить размеры ниши и зафиксировать согласованный вариант» уже позволяет понять, что делать и когда работа закончена. Такой способ управления освобождает внимание: меньше приходится угадывать намерения коллег и вспоминать договорённости.

Задачи, сроки и сигналы внимания превращают этот принцип в ежедневный инструмент. Следующий шаг становится виден, его можно поручить, выполнить и увидеть, как работа продвинулась.

Как не дать заказу застрять

Открытая задача отвечает на вопрос, что должно произойти дальше. Если задач нет и больше суток не было содержательного движения, карточка получает сигнал «Висит». Просрочка задачи и непросмотренное обновление показываются независимо: работа может одновременно требовать исполнения и содержать новое сообщение.

Ожидание тоже можно определить. Например, заказчик вернётся к обсуждению после отпуска: сотрудник откладывает напоминание на 7 или 30 дней. Это меняет сигнал внимания, сохраняя этап, задачи и историю. Предусмотрено и постоянное отключение такого напоминания для конкретной карточки.

Механизм помогает различать согласованную паузу и забытый заказ. Он не устраняет причины задержек за человека: нужно уточнить вводные, договориться о сроке, назначить исполнителя или снять препятствие. Но для поиска потерянного движения уже не приходится держать всю компанию в голове.

Архитектура без двойной работы

Внутри системы разделены бизнес-правила, хранение данных, подключения внешних каналов и интерфейс. Такой порядок позволяет менять экран, сохраняя правила заказа, и добавлять канал обращений, сохраняя связь с клиентской задачей.

Человек и программный помощник должны пользоваться одинаковыми командами и ограничениями доступа. История действий нужна, чтобы восстановить изменение. Повторно доставленное сообщение не должно создавать повторную сделку. Идентификаторы связывают производство с заказом, даже когда проект перемещён в архив.

Финансовый контур связывает поступления и расходы с работой; производственный — выпуск и расход материала. Поэтому вопрос «что происходит с заказом?» раскрывается сразу в нескольких измерениях: разговор, действие, вещь и экономика.

Карта экранов: где находится нужная работа

Ниже — полный перечень основных разделов и самостоятельных рабочих представлений текущего интерфейса. Внутри них открываются формы и просмотрщики конкретных действий. Доступность зависит от роли сотрудника; публичным остаётся только специально переданный просмотр модели.

• Вход. Рабочий email и одноразовый код из письма.
• Задачи. Свои, поставленные другим, задачи сотрудника или отдела; сроки, просрочка, выполнение, создание обычной задачи или закупки.
• Сделки: доска. Канбан с этапами; контуры продаж, поставок, производства, аудита и архива.
• Сделки: список. Те же заказы в компактном представлении с группировкой по этапам.
• Карточка заказа. Контрагент, ответственный, задачи, диалог, внутренние сообщения, файлы, цена и производственные комплекты.
• Контрагенты. Покупатели, поставщики и сервисы, поиск и переход к человеку или организации.
• Карточка контрагента. Контакты, каналы, менеджер, теги, связанные заказы и объединение дублей.
• Закупки. Задачи снабжения, поставки и таблица ресурсов: остаток, бронь, прогноз, рекомендация.
• Бухгалтерия. Сводное состояние, финансовые операции, счета и период; импорт выписок, связи, возвраты и закупленные партии.
• Знания: каталог. Категории, продукты и полнота накопленных сведений.
• Знания: продукт. Содержание, фотографии, связанные заказы, редактирование и подготовка страницы.
• Медиаплан. Истории, публикационные пакеты и отметки о размещении; открывается в контентном разделе.
• История. Дневная хронология работы компании, фильтр сотрудника и зафиксированные решения.
• Сотрудники. Приглашения, активность, отделы и управленческие полномочия.
• Машина воплощения. Доступ к подключённому производственному интерфейсу на рабочем месте.
• Настройки. Профиль, аватар, уведомления, смена email и управление сессиями; тарифы доступны уполномоченным сотрудникам.

В карточке дополнительно открываются редактор цены, панель задач, форма денежной операции, управление проектом и комплектами, производственный лист, 3D-просмотрщик, просмотр изображений и письма. Внешний просмотр модели по ссылке предназначен заказчику. Глобальный поиск доступен поверх рабочих разделов.

Общая композиция показывает примеры экранов, помогающих системе работать как единое целое. Скриншоты конкретных действий сопровождают соответствующие главы. Частные сведения размыты; интерфейс снят с реальной системы. Изображения открываются крупно.

Знание становится рабочим ресурсом

После завершения проекта остаётся больше, чем файл и фотография. Мы узнаём, какое решение подошло человеку, где потребовалось уточнение, что мешало изготовлению и как описать результат следующему заказчику.

База знаний связывает эти сведения с источником и областью применения. Для продукта предусмотрена связь с несколькими заказами: опыт одного типа вещей может складываться из разных воплощений. Из этого знания растут будущие страницы сайта, вопросы при обсуждении и правила работы.

«Чем больше знаешь — тем больше можешь» особенно чувствуешь, когда нужный опыт оказывается рядом в момент решения. Каждый завершённый проект способен сделать следующую работу понятнее. Так компания накапливает способность создавать всё более интересные вещи.

Обращения и переписка: сохранить контекст разговора

В Машине управления можно принимать обращения из подключённых каналов, находить нужный разговор и отвечать из карточки заказа. Сообщения, изображения и вложения остаются рядом с работой. Внутренние заметки помогают передавать контекст коллегам; важные записи можно выделять, а при ошибке доставки — повторять отправку.

Система различает новое обращение и продолжение действующего заказа, учитывает прочтение для конкретного сотрудника и помогает увидеть диалог без ответа. У контрагента можно задать режим входящих, чтобы сервисная переписка не засоряла поток продаж. Подключения каналов имеют собственные настройки и ограничения.

Заказы и контрагенты: один путь от продажи до архива

Заказ можно создать, принять в работу, назвать, связать с контрагентом и назначить ответственному. Доска и список показывают продажи, работу с подрядчиками, производство, аудит и архив. Переходы между этапами проверяются правилами процесса; сама карточка продолжает хранить историю.

В справочнике можно вести покупателей, поставщиков и сервисы, редактировать контактные способы, назначать менеджера и теги. Если один человек пришёл через разные каналы, записи можно объединить. Предусмотрено и объединение дублирующихся заказов. Это помогает сохранить цельный разговор вместо нескольких разрозненных историй.

Омниканальность: один человек может писать по-разному

Заказчик начал разговор на площадке объявлений, затем прислал подробности по почте и уточнил решение в социальной сети. Для компании важно узнавать одного человека и видеть его историю, сохраняя возможность ответить именно в нужный канал.

В CRM контакт хранит способ связи и маршрутизацию. При подтверждённом объединении контрагентов собираются их контакты, заказы и переписка. Дубли заказов тоже можно объединить. Поэтому переход между каналами перестаёт обязательно означать новый разговор с нуля.

Внутреннее обсуждение, сообщение сотруднику и ответ клиенту различаются адресатом. Действие «Ответить» сохраняет связь с исходной репликой и её каналом. Прочтение учитывается для каждого сотрудника, а ошибки доставки позволяют увидеть необходимость повторной отправки.

Это практический смысл омниканальности: не просто несколько значков мессенджеров, а общая память общения с сохранением адреса доставки. Для неё нужны настроенные подключения и корректная идентификация контактов. Система помогает ничего не упустить, а сомнительное объединение остаётся решением человека.

Задачи: кому продолжать и что должно измениться

Можно ставить задачи по заказу и самостоятельные задачи, назначать исполнителя и срок, уточнять содержание, менять статус и отмечать завершение. Задачи просматриваются как свои, поставленные другим, задачи подчинённых, выбранного сотрудника или отдела. Фильтр по этапу связывает ежедневную работу с общим движением заказов.

Просроченные, сегодняшние и будущие действия видны отдельно. Есть задачи снабжения и связь закупочной работы с нужным заказом. Руководитель может заметить задержку и определить продолжение. Здесь особенно важна разница между отметкой «готово» и принятым результатом: формулировка задачи должна позволять проверить, что изменилось.

Расчёт и производство: держать вещь рядом с заказом

Машина воплощения встроена прямо в карточку. При доступной локальной машине сотрудник может создать связанный проект, добавить ещё один комплект, открыть проект в средстве инженерного моделирования или его папку. Связь с заказом передаётся программно: производству не приходится угадывать, к какому разговору относится новый файл.

Обратно в карточку приходят расчёт, геометрия, производственный лист и сведения о выпуске. Несколько комплектов могут относиться к одному заказу. Рядом с комплектом доступны его лист и 3D-просмотр; прогресс показывает изготовление листов. Это соединяет коммерческую задачу с конкретными деталями, которые предстоит получить на станке.

На примере AURINKO 5 такой путь особенно понятен: у человека есть замысел дома, у проектировщика — пространственная конструкция крыши, у цеха — комплекты деталей и программа обработки. Машина управления сохраняет связь между этими представлениями. Показанные в серии модель, карты деления и фотографии монтажа позволяют проследить сам принцип от геометрии до собранной вещи.

Для создания и открытия локального проекта требуется работающая Машина воплощения на рабочем месте. Уже переданные в CRM геометрия и документы доступны через серверный контур. Эта граница важна: мобильная карточка помогает видеть производство и управлять его продолжением, а вычисления и подготовку ЧПУ выполняет соответствующий производственный инструмент.

Клиент участвует в проектировании через 3D

У комплекта в карточке есть интерактивная модель. Её можно вращать, приближать и перемещать; просмотр работает мышью и касанием. Сотрудник создаёт отдельную ссылку и передаёт её заказчику. Для просмотра не требуется вход в рабочую CRM.

В публичный ответ передаётся геометрия, без переписки, финансов и производственных документов карточки. Ссылка показывает актуальную переданную модель комплекта. Поэтому она удобна для обсуждения текущего состояния; согласованный вариант следует отдельно фиксировать в истории заказа.

Представим обсуждение крыши AURINKO 5. Вместо единственного удачного ракурса человек сам поворачивает конструкцию, рассматривает проём и задаёт конкретный вопрос. Ответ, уточнение и следующая задача остаются рядом с заказом. Такая обратная связь помогает обнаружить расхождение ожиданий до изготовления.

Клиент становится участником процесса: он видит, как замысел приобретает форму. Постоянная информированность складывается из этого доступа и регулярного общения команды, а не из необходимости самостоятельно разбираться во внутренних производственных экранах.

Цена из модели: интеллект ставит вопросы, расчёт считает

Время на ценообразование часто уходит на сбор исходных величин: сколько материала, деталей, обработки, отделки и сборки потребуется. Машина воплощения получает эти величины из модели и передаёт расчёт в CRM. Общие тарифы задают стоимость материала и операций для разных типов изделий.

В расчётном контуре предусмотрены стоимость обработки деталей и кромок, фрезерования с учётом проходов, шлифования, окраски, лакокрасочных материалов и сборки соединений. Для материалов учитываются соответствующие сорт и толщина. Это делает оценку объяснимой: изменение конструкции меняет объём работ, а изменение тарифа — их стоимость.

Редактор предложения позволяет собирать товары из вложенных позиций, задавать количество, добавлять опции, включать и отключать состав. Внутреннюю детализацию можно оставить скрытой в клиентском представлении, сохранив её вклад в расчёт. Итог пересчитывается по выбранному составу.

Например, для одного предмета можно обсудить вариант без отделки и с окраской, добавить монтаж или изменить комплектацию. Менеджер работает с понятными составляющими предложения и проверяет их, вместо того чтобы каждый раз заново измерять всю модель вручную.

Интеллект полезен в разборе запроса и подготовке объяснения: какие условия ещё уточнить, что входит в вариант, как сформулировать ответ. Числа приходят из геометрии, тарифов и введённых позиций. Мы развиваем их тесную связь, сохраняя различие между советом ассистента, прогнозной оценкой и утверждённой ценой. Экономию времени даёт повторное использование уже рассчитанных величин; конкретный выигрыш нужно измерять на проектах.

Закупки и материалы: заметить нехватку заранее

Раздел «Закупки» соединяет задания снабжения и ресурсную таблицу. Для позиции видны физический остаток, активная бронь, свободное количество, прогноз расхода на 30 дней и рекомендация к покупке. Фанера различается по толщине и сорту; учёт допускает и другие именованные ресурсы.

Бронь означает, что материал уже нужен принятой в производство работе. Физически он ещё может лежать на складе. Поэтому свободное количество считается как остаток минус бронь. В текущем алгоритме рекомендация к покупке равна положительной части суммы брони и прогноза за вычетом остатка. Это ориентир снабжения, чья точность зависит от актуальности исходных потребностей и складских записей.

Представим, что Тулитало одновременно готовит крышу и мебельный заказ из совместимого материала. Видеть лишь общее количество листов недостаточно: часть уже обещана производству. Бронь показывает это обязательство до распила. Фактический выпуск уменьшает потребность и отражается в расходе; прекращение соответствующей производственной работы освобождает резерв по правилам процесса.

Задача типа «Закупка» может выполняться вручную либо связываться с существующей или новой поставкой. Так появляется наблюдаемая цепочка: потребность → ответственный → поставщик и поставка → приёмка → изменение запаса. Контрагент-поставщик и его переписка остаются в той же системе.

При регистрации закупки указываются позиции и количество, связываются денежные операции и рассчитывается фактическая закупочная стоимость. После сохранения можно сопоставить прежнюю расчётную цену с полученной и предложить руководителю обновить тариф. Поэтому опыт закупок способен улучшать следующие оценки, сохраняя человеческое решение о применении новой цены.

Деньги: связать движение средств с настоящей работой

Упрощение бухгалтерской работы начинается с уменьшения повторного ввода. Сотруднику удобнее зафиксировать приход или расход прямо в контексте заказа, чем позже вспоминать его назначение в отдельной таблице. В карточке для этого предусмотрены команды, открывающие форму операции. Общая «Бухгалтерия» собирает движение денег, счета, запас, ожидаемые поступления и операции за выбранный период.

Банковскую выписку поддерживаемого формата можно загрузить файлом. Импорт распознаёт операции и их идентификаторы: повторная загрузка уже встреченной транзакции не должна создавать её заново. Для ранее внесённых вручную записей работает сопоставление по сумме и близкой дате; однозначное совпадение позволяет связать данные, неоднозначность требует разбора.

Есть и пример событийной автоматизации: вложение с выпиской в настроенной служебной карточке вызывает обработчик импорта. Само появление файла становится импульсом к работе программы. Сотрудник получает результат в учётном контуре, а завершение или ошибка обработчика сохраняются в журнале.

Операцию можно привязать к заказу, исправить связь, уточнить данные или исключить из рабочего учёта. Возврат связывается с исходным платежом. Закупленная партия соединяет расход денег с поступлением ресурса на склад. При этом списание материала в производство отличается от нового банковского платежа: иначе один расход легко посчитать дважды.

Практический выигрыш — внимание переносится с переписывания строк на проверку исключений: какой платёж не распознан, к чему относится расход, где возник возврат. Здесь описан реализованный управленческий учёт и помощь бухгалтерской работе; регламентированная отчётность и исполнение банковских платежей требуют своих процедур и подключений.

Знания о продуктах: сохранить опыт для следующего раза

Знание — это объяснение, которое можно использовать повторно: что мы создаём, для кого, из чего, при каких условиях, какие ограничения уже обнаружены и какими материалами подтверждён результат. Фотография показывает вещь; знание объясняет, что в ней важно и как продолжить работу с похожей задачей.

В разделе «Знания» есть категории и продукты, текст, изображения, связанные карточки заказов и черновики страниц. Продукт можно отнести к нескольким категориям и связать с несколькими воплощениями. Сотрудник находит исходный заказ по номеру, названию или контрагенту, а затем прикрепляет его к продукту.

Для AURINKO 5 это позволяет держать рядом сведения о доме, изображения и связь с выполненной работой. В новом разговоре можно использовать накопленный опыт: объяснить принцип конструкции, найти пример и определить, какие параметры нового участка ещё нужно уточнить. Сходство проектов становится отправной точкой, а пригодность решения проверяется для новых условий.

Знание влияет сразу на несколько продолжений. Ассистент использует доступные ему сведения при ответе. Контентный процесс строит объяснение продукта и канальные тексты. Механизм задач замечает неполное знание и поручает его дополнить. Изменение знания или фотографий служит основанием обновить соответствующую страницу.

Цена и производственные количества приходят из своих расчётных источников. Связанный с продуктом текст помогает правильно поставить задачу и объяснить предложение, но сам по себе не становится расчётом прочности или себестоимости. Так «чем больше знаешь — тем больше можешь» получает проверяемый смысл: следующий человек начинает с накопленного опыта.

Публикации: довести историю до человека

Медиаплан показывает истории, которые готовы к следующему действию, скачанные пакеты и отмеченные публикации. Можно открыть страницу, подготовить файлы и текст для размещения, а затем сохранить факт публикации. Содержание сайта и материалов каналов связывается с одной историей продукта.

Подготовка страницы, её выпуск на сайте и отправка в социальный канал — разные этапы. CRM даёт точку управления этим продолжением, а сборщики и подключённые службы выполняют свои части. Поэтому кнопка генерации не означает, что непроверенный текст немедленно стал публичным.

История, поиск и решения руководителя

Раздел «История» показывает день компании через связанные факты. Внутри дня события собираются вокруг сделки: переходы между этапами, выполненные задачи, изменения, объединения и производственный расход. Финансовые операции группируются отдельно; маркетинговые результаты и обновления машин имеют свои представления. Можно выбрать сотрудника и последовательно подгружать предыдущие дни.

Это позволяет задать предметные вопросы: какие заказы продвинулись, что действительно изготовлено, какие задачи завершены с опозданием, какие страницы выпущены, какие решения изменили правила работы? Из события можно вернуться к его предмету и продолжить разбор в карточке.

Для Тулитало особенно полезно сопоставление цепочки: расчёт поступил → задача подготовить предложение выполнена → заказ перешёл дальше → изготовлены листы → опубликована история. Это пример чтения процесса по его фактам, а не обещание, что каждый заказ проходит одинаковый путь без исключений.

История экономит время контроля: руководителю не нужно запрашивать у каждого отдельный пересказ дня. При этом полнота обзора зависит от того, что сотрудники и интеграции зарегистрировали в системе. Результат работы вне неё станет виден после фиксации.

Глобальный поиск находит людей, заказы и задачи. Решения руководителя можно сохранять отдельно, чтобы вместе с изменением оставалась его причина. В такой системе контроль помогает вовремя продолжить дело, а не только задним числом найти виновного.

Команда и доступ: каждому — его рабочий контур

Можно приглашать сотрудников, определять участие в отделах, назначать руководителей и управлять активностью учётных записей. Доступ к заказам, задачам, контенту и финансовой информации зависит от роли. Один сотрудник может участвовать в нескольких рабочих контурах.

В настройках доступны профиль, уведомления, смена адреса с подтверждением и контроль активных сессий. Можно отозвать лишнюю сессию и посмотреть сведения о входах. Настройки тарифов отделены от обычной работы с заказами. Разделение полномочий помогает сохранять управляемость, когда команда и число подключений растут.

Искусственный интеллект рядом с рабочим контекстом

«Спроси у Ветра» — рабочий сценарий Тулитало. В поле общения выбирается внутренний ассистент «Ветер», и вопрос относится к открытой карточке. Не нужно переносить в отдельное окно всю историю заказа и заново объяснять, чем занимается компания.

Например: «Что мы уже согласовали по этому заказу и чего не хватает для предложения?» Или: «Собери короткий ответ клиенту по последним изменениям». Это примеры запросов, а не выдуманные цитаты из клиентской переписки. Ассистент получает контекст карточки и подключённые знания, помогает собрать факты, заметить пробел и подготовить продолжение.

В диалоге можно уточнять предыдущий ответ: короткая сессия сохраняет связь между вопросами. При новом начале подаётся свежий контекст; в него могут входить уже имеющиеся изображения карточки. Вопросы и ответы остаются во внутренней ленте. Передача сообщения заказчику — отдельное действие сотрудника.

Так интеллект помогает там, где трудно заранее написать единственную формулу: понять длинный разговор, сопоставить сведения, найти недостающее и предложить формулировку. Геометрические величины и итог предложения проверяются своим расчётным контуром. Ассистенту не нужно угадывать производственную правду.

Другой реализованный сценарий — подготовка черновика страницы из знания о продукте. Мы развиваем подключение специализированных помощников к конкретным работам. У каждого должны быть определены доступный контекст, полномочия и проверяемый результат. Это позволяет расширять участие интеллекта последовательно, сохраняя понятного ответственного за обязательства компании.

Подключения: каналы, API, хуки и события

Архитектура предусматривает несколько способов связать внешнюю работу с CRM. Уже реализованные адаптеры требуют настройки учётных данных и каналов; наличие программного интерфейса само по себе не означает, что любой внешний сервис уже подключён.

• ВК и площадка объявлений. Входящие вебхуки принимают события сообщений; отдельные адаптеры выполняют отправку и работу с медиа. Вебхук — это уведомление от сервиса о произошедшем событии.
• Электронная почта. Отдельный канал принимает письма и вложения, поддерживает исходящий ответ. У почты свой механизм получения, её не требуется искусственно превращать в тот же вебхук.
• Машина воплощения. Сервисный API передаёт комплекты, оценки, геометрию, производственные листы и состояние ресурсов; в обратную сторону доступны карточки и тарифы.
• ИИ-ассистенты. Отдельная служба получает ограниченный контекст заказа или знания и возвращает ответ либо черновик страницы.
• Машина маркетинга. Знания, изображения, черновики страниц и статусы публикаций соединяют CRM со сборкой сайта и подготовкой канальных материалов.
• Финансовые источники. Импорт выписок и адаптер табличного платёжного реестра помогают переносить уже существующие данные; отдельный миграционный контур предназначен для прежней CRM.
• Уведомления и обновления. Поток серверных событий обновляет рабочее состояние, Web Push сообщает о событиях на подключённом устройстве.
• Внутренние плагины событий. Зарегистрированный обработчик реагирует на определённое событие, как импорт выписки на появление вложения.

Для нового подключения определяются входные данные, идентификаторы, права, результат и способ обработки ошибки. Повторная доставка события должна распознаваться, чтобы не создавать вторую копию той же работы. Сервисные подключения используют свой доступ; интерфейс сотрудника — его полномочия.

Так можно добавлять рынки, каналы, оборудование и специализированные службы по мере необходимости. Каждому требуется адаптер к его протоколу. Универсальность здесь достигается общей архитектурой и разработкой нужных адаптеров; готовность каждого подключения проверяется отдельно.

Оркестрация: согласовать людей, программы и следующий шаг

Оркестрация означает, что части работы продолжают друг друга по понятным правилам. Есть событие, контекст, задача, исполнитель, результат и условие перехода. Исполнителем конкретного шага может быть человек, обычная программа или подключённый ассистент. Общий процесс должен понимать, что именно завершено и что теперь можно делать.

В системе уже есть правила, которые находят незавершённые знания и истории, требующие публикации, и выдают связанную следующую задачу. Очередь учитывает уже выполненное и защищается от повторного создания одной и той же работы. Это конкретная опора для более широкой оркестрации.

Полный автономный диспетчер всех бизнес-процессов остаётся направлением развития. Мы строим его последовательно: сначала устойчивый частный сценарий, затем проверка пользы, затем расширение. Например: появился результат проекта, нужно дополнить знание; знание принято — можно подготовить страницу; страница проверена — можно выпускать историю; пришёл новый запрос — ему нужен ответственный и следующий шаг.

Надёжность здесь важнее впечатляющей демонстрации. Повтор события не должен удваивать заказ. Ошибка ассистента не должна становиться ценой для клиента. Ожидание решения должно быть видно. Чем сложнее взаимодействие внутри, тем яснее человеку должно быть, что происходит с его идеей.

Саморасширение: автоматизация в нужной точке процесса

Под саморасширением мы понимаем способность накапливать знания, обнаруживать следующую работу и получать новые правила и инструменты без переизобретения всей системы. У этого уже есть рабочие опоры: настраиваемые этапы, сервисные команды, обработчики событий и регистрируемые правила автоматических задач.

Например, механизм находит продукт с неполным знанием и ставит задачу отделу «Контент». После выполнения очередь продолжает следующую работу. Другая очередь готовит задачи публикации историй. Проверка правила и исходной сущности защищает от повторной постановки уже завершённого действия.

Автоматизацию можно проектировать в любой точке, где определимы импульс и результат: пришло обращение, появился расчёт, обнаружен дефицит, получена поставка, загружена выписка, завершилось изготовление. Для каждого такого сценария нужно подключить событие, задать условия, исполнителя и действие. Часть этих частных механизмов работает сегодня; новые сценарии добавляются и проверяются отдельно.

Направление развития — оркестрация людей, программ и ассистентов в едином описании процесса. Система должна помогать замечать повторяющийся ручной шаг, предлагать автоматизацию и включать проверенное улучшение в следующий цикл. Сегодня новые программные расширения проходят разработку и проверку; автономное создание таких расширений остаётся задачей развития.

Интересен сам цикл: выполненный заказ добавляет опыт → опыт улучшает правило → правило сокращает ручную работу → освободившееся внимание идёт на более сложную задачу. Так машина растёт вместе с компанией.

Откуда берётся многократный КПД

Сила системы складывается из ритма, ясности и памяти. Машина показывает нужную информацию в нужный момент, сохраняет накопленное знание и берёт на себя тяжёлую монотонную работу. То, что раньше требовало ручного переноса, повторного расчёта и бесконечных уточнений, становится продолжением одного процесса.

Одна модель даёт геометрию и исходные величины для цены. Один зарегистрированный выпуск сообщает о продвижении производства и расходе материала. Одно принятое знание помогает следующему разговору и следующей публикации. Сделанное продолжает работать на компанию.

Ритм поддерживает движение: завершённый шаг открывает следующий, ожидание получает причину, потерянное действие становится заметным. Человеку проще оставаться включённым в дело, когда перед ним посильное продолжение и видимый результат. Машина помогает удерживать этот ритм, а человеку остаётся разнообразная работа — придумать, выбрать, договориться, проверить, создать.

Мы стремимся к тому, чтобы команда меньше уставала от рутины и больше могла благодаря инструменту. В этом источник нашего замысла о росте КПД в десятки раз: несколько человек должны получить возможность вести объём работы, для которого при привычной организации нужны десятки участников и большой бюджет.

Это цель развития, которую мы проверяем на сопоставимых процессах. В нашей формуле КПД — принятый полезный результат относительно затраченных времени, внимания и ресурсов. Поэтому считать нужно весь путь: вместе с настройкой, проверками, переделками и качеством готовой вещи. Нас интересует растущая сила команды, которую можно повторить в следующем заказе.

Работа как игра с видимым результатом

Ощущение игры возникает, когда ясно, чего хочется достичь, чем располагаешь и что изменилось после действия. У Тулитало результат осязаем: вчера был вопрос и набросок, сегодня — модель, затем набор деталей, сборка и вещь на своём месте.

Машина управления делает эти изменения видимыми. Закрытая задача освобождает следующий шаг. Подтверждённая поставка снимает препятствие. Модель даёт предмет для разговора. История показывает, что удалось создать вместе. Накопленное знание позволяет в следующий раз взяться за более смелую идею.

Мы хотим, чтобы человек тратил внимание на выбор и создание, а повторение расчётов, перенос данных и напоминания принимала на себя система. Производственная дисциплина сохраняется, но ежедневная работа может ощущаться как исследование с понятной обратной связью и растущими возможностями.

Зачем это заказчику и партнёру

Заказчик получает более понятный путь от идеи к вещи. Сотрудник — меньше поиска и переключений. Руководитель — возможность раньше увидеть препятствие и помочь его снять. Партнёр — основу для согласованных передач: что принято, кто продолжает и каким будет результат.

Полезность машины мы намерены оценивать по времени ожидания, сроку ответа, доле работ без следующего шага, переделкам и завершению заказов. Рост числа карточек сам по себе не означает роста порядка.

Если у вас есть идея будущей вещи, начните с её описания. Если хотите сотрудничать в развитии системы, принесите конкретный процесс, в котором теряется движение. Общая работа начинается с ясного результата, который можно проверить вместе.

Несколько человек — начало большого изменения

Когда маленькая команда умеет удерживать весь путь от разговора до готовой вещи, она получает свободу пробовать то, на что раньше требовалась большая организация. Машина считает и сохраняет, связывает и напоминает. Люди придумывают, выбирают и создают. Каждый результат добавляет опыт, с которым следующая задача становится доступнее.

Для Тулитало это начало более широкого замысла: сделать инструменты и знания пригодными для других команд. Если удачный процесс можно повторить, улучшить и передать дальше, его сила выходит за пределы одной мастерской. Возникает сеть людей, способных воплощать собственные идеи и усиливать друг друга.

Повести за собой — значит дать работающий пример и возможность продолжить его по-своему. Именно так мы хотим возвращать технологическую силу своему региону и участвовать в преобразовании мира: через интеллект, воображение, открывающиеся возможности и настоящие вещи, которые уже можно потрогать.

Проект оркестрации: работа становится наблюдаемой схемой

На присланном фрагменте проектируемого интерфейса прямоугольники обозначают работы: собрать контекст расчёта, проверить проект, открыть модель. Вокруг работы обозначаются входной импульс, необходимые ресурсы, исполнитель и выход. Связи показывают, какое событие позволяет продолжить процесс.

Здесь есть и путь исключения: если машина недоступна, нужно показать остановку и определить повтор. Такая ветка делает неисправность частью управляемого процесса. Отдельно видны пакет настроек и роль архитектора — ресурсы и исполнители не теряются за одним общим словом «автоматизация».

Это изображение проекта оркестрации, а не заявление о готовности всего изображённого диспетчера. Оно показывает направление: сделать устройство работы обозримым, связать его с исполняемыми правилами и видеть, где человеку или программе нужно продолжить дело.

Технологическое ядро: языки, серверы и открытые технологии

Система разделена по роли компонентов. Это логические контуры: они могут размещаться на отдельных узлах или совместно, поэтому схема не означает фиксированное число физических серверов.

• Сервер управления. Python, FastAPI и Uvicorn обслуживают HTTP API. Pydantic проверяет структуру входных данных. SQLite хранит рабочие сущности и связи; файлы вложений хранятся отдельно от базы. Nginx принимает внешние HTTPS-запросы и передаёт их приложению.
• Браузерный интерфейс. HTML, CSS и JavaScript ES modules отвечают за экраны, формы и взаимодействие. HTTP передаёт команды и данные; Server-Sent Events доставляют обновления, Web Push — уведомления на подключённое устройство. Service Worker участвует в браузерном контуре уведомлений.
• Локальный инженерный контур. Ruby используется в плагине средства инженерного моделирования. Python выполняет преобразования геометрии, расчёты, раскрой и подготовку производства; NumPy и Shapely помогают в численных и геометрических операциях. Локальный HTTP API соединяет рабочее место с карточкой заказа.
• Геометрия и документы. JSON переносит структурированные данные и сетку модели. WebGL рисует интерактивную геометрию в браузере. SVG и PNG используются для схем, PDF — для документов; производственный контур готовит управляющий G-code.
• Служба ассистента. Отдельный Python HTTP-сервис получает разрешённый контекст, обращается к подключённой модели и возвращает структурированный результат. Взаимодействие отделено от основной логики сделки.
• Сборка публичных материалов. JavaScript и Node.js собирают страницы и проверяют структуру выпуска; Python участвует в подготовке данных и материалов. HTML, JSON-LD, XML и YML позволяют передать сведения человеку, поисковой системе и товарному каналу.

Структура рабочих сущностей и журнал отделены от кода приложения. Подключения используют определённые права, а данные проверяются на входе. Благодаря этому новый канал или помощник может продолжать общий процесс через согласованный интерфейс. Технологии становятся средством сохранить одну связь: намерение человека → проверяемая работа → настоящий результат.