Веб-приложение для теплицы: как описать посевы и партии, задать сроки созревания и получить от AI план работ и простую аналитику по выходу продукции.
Теплица каждый день принимает одни и те же решения: что сеять и где, что пора пересадить, какие грядки требуют ухода, когда начинать сбор и что готовить к отгрузке. Если опираться на память и разрозненные записи, ошибки быстро накапливаются: партии смешиваются, даты теряются, а план работ превращается в догадки.
Обычно все начинается с таблицы. Она работает, пока культур мало и все созревает примерно одновременно. Но как только появляется несколько посевов одной культуры с разными датами, таблица начинает «плыть»: строки копируются, формулы расходятся, а главное, теряется связь между посевом, реальной партией и фактом сбора.
Под партией удобно понимать проверяемый отрезок производства: один посев (или посадка) в конкретной зоне, с фиксированной датой старта и ожидаемым окном созревания. У партии должны быть свои даты и состояние, чтобы ее можно было вести от посева до последней отгрузки.
Прогноз сборов нужен не ради красивого графика. Он отвечает на практичные вопросы: когда начнется сбор по каждой партии, какой ожидаемый объем по неделям, где возможен провал или пик, который не вытянет команда, какие партии стоит сдвинуть, чтобы выровнять загрузку, и что реально можно обещать покупателю по срокам.
Когда партии описаны одинаково, автоматизация помогает без «магии»: по датам и длительности стадий система собирает план работ (что делать на этой неделе и с какими партиями) и дает сводку по ожидаемому выходу.
Чтобы веб-приложение для теплицы помогало, а не превращалось в бухгалтерию, важно договориться о простых терминах. Тогда записи будут одинаковыми у всех, а прогноз станет понятным.
Начните с четырех вещей, которые есть почти в любой теплице: культура, сорт, место и посев. Культура - это томат, огурец, салат. Сорт (или гибрид) уточняет, что именно растет. Место удобнее фиксировать как зону или грядку, чтобы сразу понимать, где находится партия.
Ключевая единица учета - партия. Она отвечает на вопрос: «что именно растет сейчас как единое целое». Обычно это одна культура и один сорт, привязанные к конкретной дате старта и зоне.
У партии полезно хранить: дату старта, плановый объем (сколько посадили), текущий статус (в работе, в сборе, закрыта) и фактический остаток, если вы фиксируете списания.
Сроки лучше хранить как этапы, а не как один «день созревания». Для старта хватит пяти этапов: посев, пикировка (если есть), высадка в теплицу, начало сбора и конец сбора.
Сразу выберите единицы измерения для каждой партии: штуки (рассада), кг (зелень), ящики (на отгрузку). Важно, чтобы план и факт были в одной единице, иначе отчеты начнут спорить сами с собой.
Отдельно заведите события и заметки по партии: обработка, подкормка, болезнь, списание, перенос в другую зону. Простой пример: «партия огурца, высадка 10 марта, зона 2». Если 20 марта была обработка и выбыло 5% растений, это событие объяснит просадку в прогнозе и в отчете по выходу.
Чтобы учет не превратился в «учет ради учета», фиксируйте только то, что влияет на план работ и прогноз сборов. Остальное добавляйте позже, когда появятся конкретные вопросы.
Посев - это факт старта. Партия - это то, что вы будете собирать и продавать. Иногда партия совпадает с посевом, иногда делится.
Для посева обычно достаточно: культуры и сорта, даты посева (или высадки рассады), зоны/грядки/секции теплицы, планового объема (в одной выбранной единице) и ответственного.
Партии имеет смысл заводить, когда появляется необходимость прогнозировать сбор, вести статус или делить объем (например, часть ушла в другой блок теплицы).
Для партии держите минимум: привязку к посеву, текущий объем, плановую дату первого сбора, статус (растет/в сборе/закрыта) и короткий комментарий (например, «пересадка», «болезнь», «досветка»).
Если технология стабильная, удобно хранить фиксированное «дней до первого сбора» (например, 38). Если условия часто меняются (погода, досветка, разные зоны), честнее держать диапазон, например 35-45 дней. Тогда приложение показывает окно, а не «точную дату», которой все равно не будет.
Зону и ответственного лучше хранить и у посева, и у партии. Тогда план работ (полив, подкормка, обработка, подготовка тары) можно строить по участкам и по сменам.
Изменения не затирайте. Если вы переносите дату сбора или корректируете объем, сохраняйте причину и дату правки. Простой подход - хранить текущие значения плюс историю корректировок.
Пример: партия салата планировалась к первому сбору на 10-е число, но из-за похолодания сдвинули на 14-е и уменьшили объем на 8%. Такая запись сразу дает понятную аналитику по зонам и людям.
Чтобы приложение прижилось, интерфейс должен отвечать на ежедневные вопросы: что посеяно, что созревает, что надо сделать на этой неделе и где есть риск срыва сроков.
На старте обычно хватает трех экранов:
Список партий удобно делать в виде таблицы: культура, сорт, зона, дата посева, плановая дата первого сбора, статус и простой индикатор риска (например, срок близко, а этапы не отмечены).
Фильтры нужны не «для красоты», а чтобы за 10 секунд найти нужное. Минимальный набор: культура, зона (или теплица/ряд), статус (план, в работе, сбор, закрыта) и период (посевы за месяц или сборы на ближайшие 2 недели).
Чтобы данные вводили без сопротивления, добавьте шаблоны. Пользователь выбирает культуру и сорт, а приложение подставляет типовые сроки по этапам. Человек меняет только даты и зону.
Уведомления должны быть короткими и только по делу. На ближайшие 7 дней обычно важны: плановые работы (подкормка, обработка, подвязка), переход этапа (например, высадка), старт сбора и дедлайн закрытия партии. Часто достаточно ленты задач на главном экране и напоминаний в календаре.
Роли тоже лучше не усложнять: агроном смотрит аналитику и план, бригадир отмечает факты работ и сборов, администратор правит справочники (культуры, зоны, шаблоны) и исправляет ошибки.
Чтобы приложение давало прогнозы и понятные отчеты, важнее всего ясные связи между сущностями. Модель лучше держать небольшой: пяти сущностей обычно хватает, чтобы закрыть учет и аналитику без путаницы.
Культуры и сорта (справочник). Здесь удобно хранить ориентиры: средний срок созревания (например, 45-55 дней), типичный выход с растения или с квадратного метра, единицу учета (кг, шт, пучки). Эти значения не обязаны быть идеальными, но они дают опору для планирования.
Посевы (факт запуска): что посеяли, когда, и какой плановый объем.
Партии (ежедневная работа): привязка к посеву, зона, объем, статус. Партии чаще всего нужны из-за разных зон, сроков высадки, плотности или потому что часть посева пошла на пересев.
Сборы (факт результата): сколько собрали и когда. У партии много сборов, а в один день может быть несколько записей.
Работы (план и исполнение): что надо сделать, к какой партии (или зоне), к какой дате, и кто отвечает.
Минимальный набор полей, который обычно покрывает отчеты:
Пример: посев огурца 10 января на 3000 растений. Вы делаете две партии: «Зона А 1800» и «Зона Б 1200». Затем каждый сбор привязываете к партии, и отчет показывает план против факта по неделям, а список работ напоминает про подвязку, подкормку и начало сбора.
Самый полезный прогноз для теплицы - календарь сборов по партиям. Он отвечает на простой вопрос: когда начнется сбор, когда будет пик и когда партия закончится. Для этого достаточно даты старта (посев или высадка), ориентировочного срока созревания и правила про длительность окна сбора.
Для каждой партии достаточно трех дат:
Например, салат с первым сбором через 28 дней и окном 10 дней: старт на 28-й день, пик примерно на 32-33-й, завершение на 38-й. Уже этого хватает, чтобы планировать людей, тару и отгрузки.
Второй слой - ожидаемый объем. Простая логика: плановый объем партии минус потери. Потери лучше делить на понятные причины (болезни, брак, пересорт, недобор веса) и хранить хотя бы процентом, если точных цифр пока нет.
Дальше появляется план-факт по неделям: сколько по плану должны собрать в неделю N и сколько собрали реально. На первых итерациях можно распределять плановый объем по неделям равномерно внутри окна сбора, а позже заменить на более реалистичное распределение (в пик больше, по краям меньше).
Из показателей обычно хватает двух: средний выход на партию (кг или штуки) с отклонением от плана и доля списаний (списано / плановый объем или списано / факт).
Важно заранее договориться о точности. Прогноз урожая в теплице всегда приблизительный: погода, свет, качество рассады, ошибки ухода и сдвиги в сроках дают разброс. Цель прогноза - не угадать до килограмма, а вовремя увидеть, что партия «уезжает» по срокам или по выходу, и поправить план работ.
Рабочий подход - собрать минимально полезную версию за 1-2 коротких цикла, а затем улучшать по факту. Сначала учет партий, потом редкие отчеты и «красота».
Потратьте 30 минут на требования: какие культуры ведете, какие зоны или теплицы есть, и как удобнее считать (кассеты, грядки, площадь). Сразу договоритесь о датах: дата старта, плановая дата готовности, фактическая дата.
Опишите поля для посевов и партий так, чтобы их реально заполняли. Оставьте только то, что влияет на план работ и прогноз: культура, сорт (если важно), зона, площадь или количество, дата старта, срок созревания (в днях) или плановая дата, статус, ожидаемый выход (кг или шт).
Соберите экран ввода и экран списка партий. В списке должно быть видно, что «горит»: ближайшая готовность, просроченные работы, партии без ключевых полей.
Добавьте календарь работ и напоминания. Не пытайтесь автоматизировать все операции, хватит 3-5 типов задач: посев, пикировка, высадка, обработка, сбор. Задачи можно генерировать по шаблону от даты старта и срока, а затем дать человеку возможность править руками.
Включите прогноз и отчет план-факт: плановая дата сбора, фактическая, ожидаемый выход и факт. Это сразу покажет отклонения.
Перед запуском внесите 5-10 настоящих партий (например, 6 партий салата и 4 партии огурца из разных зон). Быстро станет ясно, каких полей не хватает, а какие мешают.
Признаки, что вы попали в цель: заполнение партии занимает до 1 минуты, видно партии с созреванием на текущей неделе, план работ на завтра формируется без ручного поиска, а отчет план-факт показывает хотя бы одну понятную причину отклонений.
Самая частая проблема - путаница между посевом и партией. Посев - это событие (когда и что посеяли). Партия - объект учета и планирования (объем, где растет, когда ожидается сбор). Если правила нет, люди начинают создавать партии «как получится», и через месяц уже непонятно, откуда взялись цифры.
Вторая ловушка - разные единицы измерения. Сегодня считают кассеты, завтра лотки, потом килограммы. Без явного пересчета отчеты не сходятся, а прогноз начинает врать. Практичный вариант: выбрать одну базовую единицу для планирования (например, растения или м2) и одну для результата (например, кг), а пересчет хранить отдельно.
Отдельная тема - сроки. Когда даты созревания «живут в голове» или в комментариях, план работ превращается в угадайку. Даты должны быть полями, а не текстом, иначе вы не сможете автоматически собрать календарь задач.
Еще одна типичная ошибка - фиксировать только план и не заносить факт. Прогноз быстро становится красивой картинкой, которая не учится на реальности. Даже минимальный факт (дата сбора, вес, списания) уже дает пользу.
Чтобы не утонуть в деталях, держите первую версию простой. Если сразу добавить десятки статусов, причин и типов операций, приложение превращается в бюрократию.
Полезная проверка перед запуском:
Пример: внесли партию «Салат, 10 лотков» без площади и без окна сборов. Через две недели появляется «Салат, еще 8 лотков», и никто не понимает, это подсев или новая партия. Если заранее зафиксировать правило (например, каждый посев - отдельная партия, объединять нельзя) и обязательные даты, система уже сможет подсказать, какие партии близки к сбору и что готовить.
Перед тем как отдавать приложение в ежедневное использование, проверьте не «красоту экрана», а то, что данные будут стабильными через месяц. Если на старте пропустить пару базовых полей, прогнозы и планы быстро разъедутся с реальностью.
Пять быстрых проверок на реальном наборе партий (хотя бы 10-20 записей):
Мини-сценарий для проверки: выберите одну культуру (например, огурец) и заведите две партии с разными датами старта. Внесите пару фактических сборов за разные дни и убедитесь, что план на неделю пересчитывается предсказуемо, а закрытая партия не попадает в список ближайших работ.
Представим небольшое приложение, где выращивают две культуры: огурец и салат. Теплица разбита на три зоны: A, B и C. На месяц запланировано 6 партий: по 3 партии на каждую культуру, с посевами раз в 7-10 дней, чтобы сбор шел «лесенкой», а не одним пиком.
Одна партия вносится за 2-3 минуты, если карточка простая. Обычно хватает: культура и сорт, зона и площадь (например, «B, 120 м2»), дата посева или высадки, плановая дата начала сбора и длительность окна (например, 14 дней), ожидаемый выход (например, 180 кг за окно) и текущий статус.
Дальше система использует сроки и статусы, чтобы собрать план работ на неделю. Важно, чтобы в плане были не «все задачи мира», а только то, что влияет на ближайшие 7 дней.
Простой прогноз выглядит как календарь: ожидаемые сборы по дням. Например, с 10 по 23 число каждый день по 12-15 кг салата из зоны A, а с 15 по 28 число по 20-25 кг огурца из зоны B. Это помогает заранее увидеть перегруз по сбору и упаковке.
Если партия задержалась на 5 дней (болезнь, холодная неделя, ошибки полива), меняются две вещи: прогноз по дням сдвигается, а план работ перестраивается. Задачи, привязанные к фазам, тоже уезжают: сбор начнется позже, зато раньше появятся дополнительные проверки и корректировки режима.
Сначала договоритесь о минимуме, который дает пользу каждый день. Версия 1 должна отвечать на простые вопросы: что посеяно, когда созреет, что планировали собрать и что собрали по факту.
Для старта обычно хватает: ввода партий (культура, дата старта, площадь, срок созревания), календаря работ и сборов по партиям, план-факта по сбору (ожидали, получили, причина отклонений) и простых недельных отчетов по ожидаемому и фактическому выходу.
Дальше важнее всего обратная связь от тех, кто вносит данные. Попросите 2-3 человек вести учет одну-две недели и разберите конкретные проблемы: где они спотыкаются, что забывают заполнить, какие поля лишние. Часто оказывается, что удобнее один «экран смены», где можно быстро отметить сбор, списание и перенос срока, чем длинная карточка.
Когда начинаются правки, людям обычно страшно что-то менять: можно испортить прогноз или историю. Поэтому рано добавьте безопасные изменения: снимки состояния и откат. Тогда агроном может поправить срок созревания после осмотра, не теряя прошлые значения.
Развертывание и домен имеет смысл делать, когда процесс устоится. Сначала пусть это будет рабочая тестовая среда, а после закрепления правил учета переносите в постоянный режим.
Если хотите собрать прототип быстрее, такой сценарий удобно делать на TakProsto (takprosto.ai): описать сущности и правила в чате, включить planning mode, а затем при необходимости экспортировать исходники и развивать проект дальше.
Перед запуском в постоянную работу проверьте:
