Точное земледелие связано с использованием современной (умной) техники, оснащаемой бортовыми компьютерами. Такие бортовые компьютеры (их часто называют дисплеями) представляют собой надежные ударопрочные устройства, содержащие программное обеспечение для управления сельскохозяйственной техникой и прицепными устройствами.
Стоимость таких компьютеров высока. Так, один из популярных дисплеев Trimble 750 CFX DGPS стоит свыше 3 тыс. евро.
Система 1 – Дисплей
Данные устройства являются настоящими шедеврами цифровой инженерии, соединившими в себе передовые достижения переносных полевых компьютеров, специальной организации базы данных и программного обеспечения, разработанного на уровне качества, соответствующего военным бюджетам.
Дисплей – бортовой компьютер с/х техники
Данные устройства взаимодействуют с огромным множеством электронно-механических устройств, установленных на технике. Структура баз данных полевых компьютеров достаточно развитая. По составу информационных сущностей она сравнима с информационными системами управления растениеводством (farm management, FMIS). В этих базах данных содержится информация:
- о видах техники,
- видах прицепного оборудования с параметрами работы,
- операторы,
- номенклатура внесения в почву,
- список сельскохозяйственных полей с координатами,
- список сельскохозяйственных операций.
Некоторые дисплеи содержат также понятие производственного подразделения. Из этого следует, что настроить такой дисплей для работы – не просто. Тут, как говорится, нужен компьютерщик. И механизаторам приходится становиться отчасти такими компьютерщиками.
Рабочее место механизатора
Производители дисплеев подумали об этой проблеме. Они не рассчитывают, что механизатор всегда сможет правильно настроить дисплей. Предусмотрели так, чтобы работа на поле была сделана, несмотря ни на что – несмотря на неправильно настроенный дисплей, несмотря на то, что информация вводится с орфографическими ошибками – главное, чтобы механизатор мог сделать свои гектары и получить зарплату. В настоящее время так «живет» абсолютное большинство наших агрохолдингов. Технику купили, дисплеи к ним тоже купили, а с полноценным использованием дисплеев – проблемы.
Система 2 – «облако» производителя техники
Производители умной техники понимают, что надо как-то автоматизировать эту «неразбериху» с дисплеями в хозяйствах. Понимают, что сделать надежный трактор или сельхозорудие – этого уже мало. Необходимо включать его в контур централизованного управления оборудованием. Следуя этому, производители разработали свои «облака» (будем использовать этот термин) – информационные системы, которые предназначаются для подготовки данных для дисплеев и для приема информации от них.
Облако производителя техники
Структура базы данных «облака» во многом похожа на структуру базы данных дисплеев. Есть и принципиальные структурные различия в этих системах – так, например, в «облаке» надо управлять гораздо шире: нужен список хозяйств, права доступа, типы дисплеев, интерфейсные решения для визуализации множества техники и многое другое. Но главная функциональная проблема, которую решают в «облаке» – этот минимизация хаоса, который возникает в результате обмена данными с дисплеями.
Чтобы понять это, рассмотрим простую ситуацию. Механизатор настраивает дисплей, вводит название удобрения, которое собирается вносить – «амиачная силитра». Если трактор не оборудован RFID-меткой механизатора, вводит оператора – «Сергеев». Начинает работать. Потом данные передает в «облако». В облаке выполняется поиск «Сергеев» – не находится, потому что там записано «СергеевАВ» – создается новый оператор «СергеевАВ». То же самое по «амиачной силитре», создается дубликат, потому что сделано две орфографических ошибки, а в облаке введено правильно. Мне могут возразить, скажут, что так можно «сломать» любую систему, мол, надо принимать организационные меры – запретить механизаторам вводить строковые настройки на дисплеях, формировать задания только из «облака», и так далее. Я с этим полностью согласен – это решит проблему. Однако решит проблему только для небольших хозяйств.
Для Российских агрохолдингов это не подходит. Этот тезис является следствием понимания замысла «облака», который заключается в том, чтобы, с одной стороны, облегчить (централизовать) настройку дисплеев, с другой стороны, автоматизировать прием данных документирования сельскохозяйственных работ от дисплеев для визуализации результатов конечным пользователям – агрономам и агроаналитикам хозяйства. Сложность взятой на себя задачи состоит в том, что система должна обслуживать огромное количество техники – со всего мира. И здесь на первое место выступают вопросы юридической конфиденциальности данных, надежности их хранения, быстродействия системы, универсальности функционала для всех агрохозяйств – и для Китая, и для США, и для Бразилии, и для Индии, и для России, и для Лихтенштейна. Понятно, что чудес не бывает, везде не успеешь. Логично, что «в жертву» приносятся развитость функционала, адаптируемость под специфику управления, и другие вопросы «последней мили» для агрохолдинга как функционал встраивания бизнес-процессов работы с техникой в корпоративную информационную систему. Теперь становится понятным сказанный выше тезис – в «облаке» реально управлять парком техники только для небольших хозяйств.
Производители умной техники это прекрасно понимают и предлагают выход из этой ситуации: дают API, дают возможность сторонним разработчикам программного обеспечения сделать свою «последнюю милю» – интегрировать работу с умной техникой в производственную информационную систему агрохозяйства.
Система 3 – FMIS
Разберемся теперь с третьей хорошей системой «на нашем пути» – это FMIS (Farm management information system) – производственная система управления растениеводством.
Что она делает? С первого взгляда, примерно то же что и «облако», но здесь уже акценты смещены на эффективность работы производственных подразделений. Если в «облаке производителя техники» акцент был на то, чтобы централизованно минимизировать участие механизаторов в настройке дисплеев, то в FMIS акцент на то, чтобы агрономы и диспетчеры могли быстро реагировать на изменяющуюся ситуацию, могли менять план работ в режиме «онлайн», а изменения в план работ вносить не только «по телефону», но и в информационной системе FMIS.
Если в «облаке» акцент был на то, чтобы иметь историю обработки полей по данным от техники, то в FMIS акцент смещается на то, чтобы иметь гибкое планирование работ согласно технологической карте, иметь «перед глазами» актуальную план-фактную картину того «что сделано и что надо сделать завтра и послезавтра и в ближайшую неделю», анализировать причины отклонений от графика, работать в связке с экономистами и бухгалтерами компании. Еще один ключевой акцент – «облаков» разных производителей техники может быть много, а FMIS для агрохолдинга – одна, и она должна уметь работать с техникой разных производителей, и «умной» и «простой» (например, через телематическую систему Wialon). Поэтому без FMIS – никак не обойтись, если в хозяйстве обрабатывается более 20 тыс. га, а таких хозяйств в России – несколько сотен.
Спрос рождает предложение. Систем FMIS разработано много, и зарубежных и отечественных. Для ориентира – мне известны более 15 систем, заслуживающих внимания. Каждая из систем имеет свои сильные стороны. Вернемся к теме статьи, ответим на вопрос: «умеют ли FMIS формировать задания для дисплеев?». Почти все FMIS ответят: «да». Спросим: «какая информация передается в задании?». Почти все FMIS ответят: «мы у себя готовим предписание в виде shp-файла и передаем либо в «облако» либо на флешку для последующей загрузки в дисплей». Хотя передача через флешку для ряда дисплеев все еще является основной, в этой статье мы не будем ее рассматривать, отнесемся к флешке как к «уходящей» технологии.
При передаче предписаний через «облако» предполагается, что недостающую настроечную информацию на дисплее внесет механизатор. Такой информацией в разных дисплеях может быть: выбор прицепного оборудования и настройка его параметров, название задачи, название продукта внесения, название культуры на поле, название поля, ФИО оператора и др. Другими словами, на дисплей передаются, как правило, всего лишь границы полей и зоны обработки с нормами внесения. Остальное надо дополнять или в «облаке» или на самом дисплее. Если дополнять в «облаке», выше было показано, что «облако» не подходит для крупных хозяйств. Если дополнять на дисплее, выше было описано почему это плохо.
Эти возможности формирования и передачи предписаний позиционируются разработчиками FMIS, в основном, как возможности обработки по зонам – то есть, возможности точного земледелия. Однако, для Российской действительности, скажем так, это неактуально в 99 случаях из 100. Понимая эту «редко используемую» роль функционала зональных предписаний, хозяйственники не придают этому большого значения. Таким образом, разработчики FMIS живут в иллюзии, что у них с этим все в порядке, и не берут на себя инициативы разработки полноценного функционала подготовки заданий для дисплеев. По правде сказать, «виноваты» в этом не только разработчики FMIS. Еще многие «облака» не готовы к этому. Точно знаем, что «облако» John Deere к этому полностью готово. По остальным, надо уточнять. Но даже несмотря на готовность «облака» John Deere «пропускать через себя» практически 100-процентную настройку своих дисплеев, в мире можно по пальцам одной руки посчитать системы FMIS, которые умеют с этим работать.
Просмотр настроек на дисплее John Deere
Мы рассмотрели возможности FMIS формировать полноценные настройки дисплеев. Теперь рассмотрим обратный поток данных – передачу данных от дисплеев в FMIS через «облако». К решению данной задачи «облака» сейчас вполне хорошо готовы.
«Облачные» API отдают детальную информацию о результатах сельхозработ: и цифровую и картографическую. Однако разработчики FMIS «не торопятся» реализовывать достаточно развитый и удобный функционал. Уровень реализации можно охарактеризовать как «для галочки». Поэтому выполнять анализ выполненных работ все еще удобнее в «облаке», чем в FMIS.
Возникает логичный вопрос, почему при хорошей готовности «облака» отдавать сельскохозяйственные данные, системы FMIS до сих пор c с малым темпом наращивают свой функционал? Ответ в том, что задача оказалась сложной. При интеграции приходится согласовывать разные по структуре модели баз данных, решать вопросы однозначной идентификации по-разному называемых записей, синхронизации изменений, приведения к единым учетным единицам измерения площади, расстояний, объема и веса, и множество других вопросов. При этом также необходимо предусмотреть интеграцию с разными «облаками производителей техники». Хотя в этом вопросе сейчас есть встречное движение – «облака» пытаются стать интеграторами данных не только «своих» дисплеев. Но на этом пути не стоит ждать большой открытости. Потому что каждый производитель техники, исходя из коммерческих целей, всегда будет держать функционал для своей техники более развитым, а для чужой техники – с ограничениями.
Есть другой вариант решения этой проблемы. Начали возникать независимые от разработчиков техники решения – конвертеры данных от разнородных дисплеев, типа ADAPT, продукты для централизованного сбора и маршрутизации сельскохозяйственных данных от разных видов техники, типа Agrirouter. Это очень хороший тренд, он ведет к унификации работы с разными форматами данных. Однако эти продукты эффективны только лишь для обеспечения входящего/исходящего потока данных в/из FMIS.
Сложность интеграции лишь незначительно уменьшается. На стороне FMIS необходимо предусмотреть весь комплекс процедур для управления изменениями данных.
Например, техника объехала поле. Передала данные в «облако». В FMIS надо предусмотреть процедуру импорта нового поля.
Второй пример, внутри FMIS выполнили корректировку границ поля. Необходимо обновить информацию в «облаке». Если этого не сделать, то аналитика «в облаке» будет неверной. Нужна соответствующая процедура внутри FMIS.
Третий пример, трактор сделал по определенному полю навигационную линию «А-B» – отработал – на поле возникла колея – необходимо именно эту навигационную линию передавать в заданиях и на другую технику, работающую на этом поле.
Четвертый пример, внутри FMIS необходимо посмотреть все карты покрытия по уборке урожая за неделю по озимой пшенице, чтобы визуально сравнить поля по урожайности.
Таких примеров востребованного функционала на стороне FMIS очень много. Дополнительную сложность придают особенности хозяйствования в разных агрохолдингах. Но, пожалуй, самым неприятным моментом является то, что в этой интеграции мы имеем дело с точкой согласования систем с двумя разными целями.
Как писалось выше, цель техники и облака – чтобы техника выполнила сельхозоперацию «в любом случае», несмотря на то, что дисплей настроен с ошибками.
Цель FMIS – «разложить все по полочкам» так, чтобы не было дубликатов данных, была полнота и непротиворечивость данных, соблюдалась своевременность получения и отсылки данных. Именно из-за расхождения этих целей задача интеграции «облака» с FMIS усугубляется, становится сложной для решения.
Система 4 – ERP
Перейдем к четвертой хорошей системе, которая является основой для финансового управления в агрохолдинге – это ERP-система. В России чаще всего применяются системы на платформе «1С-предприятие», такие как «1С:ERP Агропромышленный комплекс», «1С:Предприятие 8. Управление сельскохозяйственным предприятием» и еще 2-3 системы. Эти системы имеют в своем составе подсистемы производственного учета, позиционирующиеся как FMIS. Однако главной задачей ERP-систем является не производственный учет, а финансовый – бухгалтерский, налоговый, экономический, кадровый. Встроенные FMIS не отражают специфики решаемых задач в растениеводстве (об этом подробнее см. в предыдущей статье).
Поэтому, для обеспечения должного уровня объема и динамики решаемых задач в растениеводстве, как правило, используется отдельная FMIS. Там же в упомянутой статье в седьмом вопросе показаны сложности интеграции ERP-системы и FMIS через API.
Добавим, что ежедневно в ERP возникают сотни документов сельскохозяйственного учета: учетные листы тракториста-машиниста, путевые листы и другие документы. Данные для них должны быть максимально объективны, максимально «взяты с техники». На первое место в учете выходят понятия экономических нормативов по объемам работ и по топливу, методы начисления зарплаты механизаторам, увязки производственных справочников с бухгалтерской аналитикой, и другие. Однако следует подчеркнуть, что, несмотря на свои сложности, у этой интеграции нет конфликта целей – цель одна и у FMIS и у ERP – «все разложить по полочкам». С этой точки зрения – задача проще, чем интеграция FMIS c «облаком».
Системы ERP представляют собой большие и сложные системы, их модификация связана с большими затратами. Поэтому примеры успешной тесной интеграции FMIS и ERP можно пересчитать по пальцам. Так, в одном из наших проектов реализован бизнес-процесс, когда на стороне ERP утром (или накануне вечером) вводятся учетные листы тракториста-машиниста в части задания механизатору; затем эти задания переходят в FMIS и «уходят» на технику; далее по данным от техники формируют оперативную сводку выполненных работ, увязанных с заданиями и экономической базой нормативов по объему и по топливу; и, наконец, выверенные диспетчером данные оперативной сводки «уходят» в те учетные листы, в которых утром (вечером) были сделаны задания. Бухгалтер затем проверяет и проводит документы по балансу.
Есть хороший совет «правильно заданный вопрос – уже половина ответа». Перефразируем этот совет «правильное понимание предметной области – уже половина качественной постановки задачи», а именно с этого начинается сотрудничество. В статье предпринята попытка осмысления текущей ситуации в растениеводстве – «почему и техника классная, и системы по отдельности хорошо решают свои задачи; а чтобы вместе слаженно заработали, у разработчиков вечно находятся какие-то «оговорки».
Правильное понимание причин является ключом к более конструктивному диалогу между сельхозтоваропроизводителями, производителями техники и разработчиками программного обеспечения, что, несомненно, будет на пользу всем сторонам процесса.