Подписанный договор ещё не стал рабочим планом
Компания завершила этап проекта, но не может вовремя подготовить расчётные документы. Нужное приложение осталось у исполнителя, срок предъявления отсчитывается от события, которое никто не зарегистрировал, а ответственный уверен, что документы готовит другой отдел.
Файл договора хранится в доступной папке. Проблема в том, что его условия не связаны с ежедневной работой. Сотрудники видят задачи и платежи отдельно, но не понимают, какое действие требуется для перехода между ними.
Обязательство в рабочей системе — проверяемое требование с владельцем, условием исполнения и подтверждением. Такая запись помогает организации контролировать процесс. Она не заменяет толкование договора и решения уполномоченных специалистов.
Начните с одного типа обязательств
Не пытайтесь сразу перенести в систему все положения всех договоров. Выберите повторяемый процесс: этапы сервисных работ, проектные поставки или регулярное обслуживание. Затем найдите условия, которые действительно создают задачи и контрольные события.
Полезно различать несколько объектов:
- обязательство описывает требуемый результат;
- задача организует конкретное действие сотрудника;
- подтверждение показывает, что произошло;
- решение ответственного определяет дальнейший шаг;
- платёж отражает отдельное событие расчётов.
Одно обязательство может потребовать нескольких задач. Завершение последней задачи не всегда доказывает исполнение обязательства: может отсутствовать подтверждение или оставаться замечание.
Содержание карточек и правила их закрытия должны согласовать специалисты, работающие с соответствующим видом договора. Разработчик не должен самостоятельно извлекать окончательные обязательства из неоднозначного текста.
Условный пример: три этапа сервисного проекта
Вымышленная компания выполняет обследование, настройку и обучение сотрудников заказчика. Для внутреннего контроля создано три этапа. У каждого есть ответственный за работу и ответственный за комплект документов.
По условному внутреннему описанию второго этапа нужны подтверждённый результат настройки и согласованный комплект из отчёта и приложения. После проверки комплект передают сотруднику, который готовит следующий расчётный шаг.
Настройка завершена во вторник. Отчёт готов, но приложение с перечнем оборудования отсутствует. В системе состояние этапа выглядит так: «работа завершена; комплект неполный; требуется приложение». Оно не превращается ни в «этап полностью закрыт», ни в «оплата просрочена».
Владелец приложения получает конкретное действие. После его выполнения ответственный повторяет проверку комплекта. Только затем фиксируется готовность к дальнейшей процедуре, принятой в компании.
Пример условный: состав документов и последствия их наличия определяются конкретным договором и специалистами, а не предложенной здесь схемой.
Сделайте карточку обязательства достаточно точной
Хорошая карточка позволяет человеку понять ожидаемое действие без повторного чтения всего файла, сохраняя при этом связь с исходным условием.
Рабочий шаблон:
- Идентификатор: ОБ-204, связь с договором и его действующей редакцией.
- Содержание: подготовить комплект по второму этапу.
- Основание: указанный специалистом раздел договора или приложения.
- Владелец: руководитель проекта.
- Исполнитель действия: координатор документов.
- Условие начала: подтверждённое завершение настройки.
- Подтверждения: отчёт и приложение по согласованному перечню.
- Следующий шаг: проверка комплектности уполномоченным сотрудником.
- Исключение: открытое замечание по результату этапа.
Если срок зависит от события, храните само событие, дату его подтверждения и правило расчёта. Не подставляйте дату автоматически из произвольного изменения статуса. Разные события могут выглядеть похожими, но иметь разный смысл.
Отделите факт от оценки готовности
Исполнитель сообщает, что работа выполнена. Руководитель подтверждает результат. Координатор проверяет документы. Финансовая роль видит готовность к своей операции. Эти действия могут происходить в разные дни.
Система должна показывать основания состояния. Фраза «готово к предъявлению» полезна только вместе с перечнем проверенных условий и решением ответственного. Автоматическая проверка комплектности помогает, но не должна выдавать юридическую оценку наличия права требования.
Аналогично платёж нельзя считать состоявшимся по отметке менеджера «клиент обещал оплатить». Для него нужен согласованный источник факта. Обещание, плановая дата, подготовленная операция и подтверждённое поступление — самостоятельные данные.
Такой подход уменьшает неоднозначность даже без сложной автоматизации. Первую карту процесса можно собрать из нескольких карточек и разобрать на одном завершённом проекте.
Покажите зависимости между обязательствами
Часть обязательств компании зависит от действий контрагента: предоставления исходных данных, доступа на объект или согласования результата. В системе такие зависимости должны быть видны.
Если исходные данные не поступили, задача исполнителя не должна выглядеть просто забытым поручением. Карточка показывает недостающее событие, владельца коммуникации и согласованное следующее действие.
При этом статус «ожидание клиента» не освобождает от управления автоматически. Нужен ответственный, который проверяет ситуацию и фиксирует результат. Иначе этот статус становится бессрочным складом проблем.
В отчёте руководителю полезно разделять просроченные действия сотрудников, неподтверждённые внешние события и спорные состояния, требующие решения специалиста. Это разные причины и разные способы работы.
Как учитывать изменения договора и исключения
После изменения условий прежний план может перестать соответствовать действительности. Нельзя просто заменить дату в карточке и потерять объяснение.
Сохраните связь изменения с основанием, автором и затронутыми обязательствами. Ответственный определяет, какие записи изменяются, какие отменяются, а какие остаются действующими. Завершённые действия не исчезают из истории.
Для частичного исполнения заведите понятный остаток работы или отдельный этап, если это соответствует процессу. Для спорного результата сохраняйте замечание и владельца решения. Не закрывайте исходное обязательство только потому, что создана новая задача.
Что автоматизировать в первой версии
Начните с карточек обязательств, связей с договором, событий, документов, ответственных и очереди исключений. Добавьте напоминания о конкретных действиях, а не одинаковые сообщения обо всех открытых записях.
Интеграцию с учётной системой ограничьте понятными фактами: например, регистрацией документа или подтверждённым платежом. Источник и смысл каждого события должны быть согласованы. Об общей организации обмена рассказывает статья об интеграциях систем.
Не включайте автоматическое толкование всех договоров в обязательный объём первой версии. Полезнее обеспечить надёжную работу с небольшим набором обязательств, которые уже описали специалисты компании.
Проверяйте карточки на завершённом проекте
До запуска возьмите обезличенный проект, который команда уже прошла вручную. Восстановите обязательства и события в хронологическом порядке. На каждом шаге спросите: какое действие система предложила бы сотруднику и на основании каких сведений?
Так обнаруживаются формально удобные, но бесполезные статусы. Например, «ожидает документы» не объясняет, какого файла не хватает и кто его готовит. Замените такую неопределённость конкретной связью.
Отдельно проверьте обратный путь: от полученного платежа к этапу, подтверждениям и исходному обязательству. Если связь восстановить невозможно, будущий отчёт будет показывать суммы без объяснимой истории исполнения.
Готовая система или собственная разработка
Готовое решение подходит, если умеет связывать договор, этапы, документы и состояния с нужной детализацией. Проверяйте зависимости от событий, частичное исполнение и изменение условий после запуска работ.
Заказная разработка может потребоваться, когда обязательства тесно связаны с нестандартным производственным или сервисным процессом. Иногда достаточно связать существующий договорный реестр с проектной системой, сохранив каждому инструменту его роль.
Перед выбором проверьте: виден ли владелец каждого действия, объясним ли статус, сохраняется ли история изменений, можно ли найти недостающее подтверждение, отделён ли факт оплаты от ожидания.
Для разговора с ExtentLab подготовьте обезличенный договор одного типа и цепочку одного этапа от работы до расчётов. Это позволит обсуждать конкретные зависимости и границы разработки, не превращая проект в неопределённую «систему управления всеми договорами».