Перспективы информатизации рыбной отрасли (инфографика)

Сегодня, как и раньше, рыбопромышленники сталкиваются с проблемами информатизации. Помимо использования информационных технологий для информационного обмена внутри предприятия: информационные системы (ИС) «Бухгалтерия», «Кадры» и проч., есть ещё и ИС внешнего контура, информационный обмен в котором для рыбопромышленников является обязательным. На протяжении последних 20 лет разработаны и внедрены информационные системы: «Отраслевая система мониторинга» (ОСМ), «Меркурий», «Регистрации захода и отхода судов» (далее для сокращения будем эту систему называть «Отход»), налоговой отчетности и другие. Причем разрабатываются эти системы разными ведомствами с разным уровнем удобства для пользователей.

Использование современных компьютерных технологий (IT-технологий) для информационного обмена – требование времени. Число задач, решаемых с использованием этих технологий, растет. Однако, как в любом деле, применение IT-технологий не дает положительного эффекта автоматически. Нельзя сказать, что после разработки и внедрения информационной системы все будет хорошо – нет, для многих пользователей этой системы все как раз становится плохо. Конечно, рано или поздно недостатки ИС будут устранены. Потренировавшись на пользователях, узнав их мнение и пожелания, можно ИС доработать, до-внедрить.

Как, используя современные тенденции развития IT-технологий, сделать процесс внедрения ИС в рыбной отрасли эффективным? Попробуем на примере ОСМ проанализировать ситуацию и сделать некоторые выводы.

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

ОСМ успешно внедрена, работает и совершенствуется. В этом процессе развития ОСМ есть препятствия, о которых стоит упомянуть и, в свете использования современных IT-технологий, найти решения по их устранению.

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

О внедрении технологии ЭПЖ.

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

Из-за технических и финансовых ограничений в ССД включаются не все данные из журналов. Например, из промыслового журнала в ССД вместо данных по каждой промысловой операции есть только суммарный за сутки вылов по объектам промысла и общее количество операций. Может для контроля промысла этого и достаточно, но явно мало для сырьевой науки. В истории российского рыбного промысла существовала отчетность по операциям в дополнение к ССД. Данные эти готовились вручную, в них было много неточностей, передавали эту отчетность не все суда. А с 90-х прошлого столетия и вовсе эту отчетность отменили.

Возродить промысловую отчетность в полном объеме предполагается на базе технологии «Электронный промысловый журнал» (ЭПЖ).

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

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

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

Первая программа, реализующая технологию электронного промыслового журнала (ЭПЖ), была разработана и применена в 1997 году в рейсе судна «Агинский». Затем внедрялась на краболовных судах. Но после 1999 года нужно было запускать ОСМ, промысел камчатского краба закрыли и задачу обязательнойкомпьютеризации промысловой отчетности отложили.

В 2004-2005 году ОСМ заработала в полном объеме и настала, как говорится, пора. В Москве создали ЦСМС, и он начал периодически докладывать о готовности внедрять какую-то из программ ЭПЖ. Подготовка, 5 лет испытаний, потом опять подготовка, потом 5 лет испытаний…

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

О порядке оснащения судов ТСК

С момента ввода ОСМ в эксплуатацию в 2000 году был выпущен соответствующий нормативно-правовой акт, определяющий порядок оснащения судов техническими средствами контроля (мониторинга) — ТСК. Через 2-3 года под давлением производителей судовых станций Инмарсат-С был выпущен перечень моделей ТСК, допускаемых к применению в качестве ТСК ОСМ, хотя никаких правил создания такого списка не было.

Этот перечень долгое время толком никто и не использовал, однако с 2016 года Росрыболовство выпустило ряд нормативных документов по данному вопросу. Сначала вышел приказ № 294, потом дополнение к нему в 2017 году, потом дополнение к нему в 2018 году и, наконец, 15.10.2018г. выпускается приказ № 525 «Об утверждении Порядка оснащения судов техническими средствами контроля, их видов, требований к их использованию и Порядка контроля функционирования технических средств контроля».

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

Например, согласно документу ТСК судно должно передавать в РЦМ некорректируемые данные. Но координаты, определяемые на борту судна с использованием Инмарсат-С, могут быть скорректированы, причем без повреждения каких бы то ни было пломб (например, с использованием симулятора сигналов GPS). Только устройства, обеспечивающие доплеровские определения координат, позволяют считать данные позиционирования абсолютно достоверными (некорректируемыми).

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

Решение об использовании транспондеров АИС в качестве дополнительного ТСК является весьма сомнительным. В АИС так же, как и в станциях Инмарсат-С координаты могут искажаться экипажем судна. На берегу доступ к данным АИС третьих лиц ничем не ограничен. Но даже при этом, согласно п.3 допускаются только аппараты со встроенным навигационным приемником. Следует учитывать, что традиционный транспондер АИС берет координаты с основного GPS судна. Таким образом, возможно, что многим судовладельцам придется покупать на свои суда вторые АИС со встроенными GPS-приемниками. В перечне разрешенного оборудования допущены два аппарата АИС класса B, но от этих аппаратов на спутники будет поступать крайне мало позиций, так как их мощность излучения теоретически должна составлять 2 Вт, а не 10 Вт как у класса A.

Думаю, лучше было бы оформить все необходимые разрешения и включить в список ТСК датчики системы АРГОС. Фирма CLS уже давно имеет транснациональный характер, производит дешевое, надежное оборудование – ТСК, полностью соответствующее современным требованиям. Задачу мониторинга маломерного флота и РПУ без оборудования этого типа не решить.

Что касается судов маломерного флота, осуществляющих доставку уловов в живом или охлажденном виде в пункты сдачи. Уточнение данных промыслового журнала в части распределения вылова по видовому составу, можно осуществлять на берегу после выгрузки и пересчета улова. Ведению ЭПЖ это не мешает, если программа формирования ЭПЖ проста и комфортна в эксплуатации. Кстати с датчиками Аргос ЭПЖ как раз сопрягается очень хорошо. После поэтапного перехода судов персонального учета на технологию ЭПЖ дело дойдет и до маломерных судов и РПУ.

О разрешениях на промысел

В Росрыболовстве «разрабатывается новая редакция закона об использовании ПК ЭПЖ, которая предусматривает поэтапный переход к использованию электронных разрешений на добычу (вылов) водных биологических ресурсов, исключая необходимость наличия на судне соответствующего разрешения на бумажном носителе».

Вообще наличие разрешения на добычу, да ещё и с оригинальной подписью, на судне необходимо для чего? Убедиться в наличии разрешения на судне можно только высадившись с проверкой на судно. Но перед проверкой можно получить сведения о разрешении запросив берег. Тем более, что эти данные в Пограничное управление ФСБ предоставляются напрямую с Территориального управления Росрыболовства, которое и выдает разрешения. Тогда зачем проверять наличие этого документа на судне? Чтобы быть уверенным, что капитан читал этот документ? А вдруг он его не читал? Но может быть корабль не может связаться с берегом? Так ведь корабль – не патрульная машина ДПС, проверяющая наличие у меня прав вождения автомобиля, связь быть должна. А если нет — тогда не проверки нужно проводить, а следовать в порт на ремонт.

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

О формировании ССД с использованием компьютеров

По тому же документу: «с целью создания единой нормативно-правовой базы по вопросам использования ПК ЭПЖ Росрыболовство планирует ввести изменения в Правила рыболовства всех рыбохозяйственных бассейнов, предусматривающие возможность подачи судовых суточных донесений (далее – ССД) с использованием ПК ЭПЖ».

Никто никогда передачу ССД с помощью программ ЭПЖ не запрещал, тут и разрешать нечего. Более того, на многих судах уже давно готовят ССД с использованием соответствующих компьютерных программ.

О программах и деньгах

Росрыболовство своим распоряжением от 10 января 2019 года №1-р обязал ФГУП ЦСМС организовать на договорной основе эксплуатацию ПК ЭПЖ, т.е. собирать с рыбопромышленников деньги за то…, что они представляют Росрыболовству свои данные.

Тут вообще интересная история. Сначала была идея брать деньги за программу ЭПЖ, разработанную программистами за бюджетные деньги. Но это как-то неправильно, да и программ таких уже много разработано. Значит решили брать деньги за «обслуживание» программы.

Описывать перипетии долговременного внедрения ЭПЖ можно долго. К сожалению, за последние 15 лет в отрасли принималось достаточно много ошибочных решений (например, отмена приказа №185 о представлении ССД).

Предшественниками современной версии информационной рыбопромысловой системы были ранее внедренные бассейновые информационные системы, ИС «Оперативное управление», ИС «Рыболовство» и ОСМ. При их создании много внимания уделялось разработке концепции, формулировке целей и задач, технико-экономическому обоснованию, техническим заданиям к разрабатываемым и внедряемым частям информационной системы. И во всех документах подчеркивалась преемственность совершенствования или создания новой ИС с богатым историческим опытом информатизации рыбной отрасли.

Информатизация отрасли это, прежде всего автоматизация обмена документами между органами государственного управления и предприятиями (и физическими лицами). В этом обмене можно выделить:

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

Эти задачи и были решены в ИС-предшественниках с разной степенью автоматизации. С развитием компьютерной техники и средств связи уровень автоматизации в ИС возрастал. Это приводило к тому, что затраты рыбопромышленников на документооборот снижались, за исключением случаев необходимого увеличения объема промысловой отчетности. Весь объем данных, которые необходимы для управления промыслом на ранних стадиях развития ИС, начиная с 1968 года, в силу технических трудностей собрать не представлялось возможным. Однако с появлением морских средств передачи данных (информации в компьютерном виде), спутниковых систем навигации, персональных компьютеров, задача автоматизации формирования и представления промысловой отчетности стала успешно решаться.

В 1993 году систему промысловой отчетности после перестройки начали восстанавливать в минимальном объеме. А уже 1996 году вышел приказ №185, согласно которому ССД, оперативные и статистические промысловые отчеты были восстановлены в полном объеме. На затратах рыбопромышленников ввод в действие новой инструкции ССД практически не сказался (и сегодня приказу №185 нет альтернативы). С 2000 года было введено спутниковое позиционирование и опять государство позаботилось о том, чтобы внедрение мониторинга не было затратным для промышленников. ОСМ внедрялась на станциях Инмарсат-С, которые уже стояли на судах, и государством оплачивался трафик за сбор позиций судов.

На пути совершенствования ОСМ – технология ЭПЖ – это очередной шаг в развитии системы сбора промысловой отчетности. Решается задача включения в ССД данных пооперационного вылова. Совершенствуется система защиты промысловых данных от неумышленных ошибок и фальсификации.

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

Особенно это важно для малых и средних предприятий рыбной промышленности. Если затраты на электронный информационный обмен не будут снижаться, малые предприятия просто не выдержат конкуренции с крупными судовладельцами. Что такое для БМРТ заплатить 100т.руб. за какую-то программу. Да если при этом все оставят судно в покое – да не вопрос! Для малых и средних предприятий, работающих на маломерных судах и на РПУ, это существенные затраты, да ещё и плюс ко всем остальным расходам.

Вот и будет в отрасли полу-мониторинг: компьютеры, мониторы, электронные карты, интернет на отдельных крупных судах, как витрина, и короткая сводка о вылове переданная непонятно из какой квартиры, непонятно о каком РПУ…

О том, что дальше делать

Выше приведенное упоминание об ошибках сделано не для того, чтобы кого-то обвинить в бездействии и некомпетентности. Я готов поддержать тех, кто говорит, что не может быть совсем плохо, если специалисты ЦСМС так долго трудились, да и денег потратили немало. Но ведь можно сделать ещё лучше!

Так что вернемся к нашей задаче эффективного использования современных тенденций развития IT-технологий в процессе внедрения ИС в рыбной отрасли.

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

В рамках этих технологий разработаны ОСМ, «Меркурий», «Отход». Есть программное обеспечение (ПО) серверной части и есть ПО клиентское. В ОСМ и системе ОТХОД мы видим только клиентскую часть. В системе Меркурий дополнительно к клиентскому приложению сделан API-интерфейс.

На сегодняшний день API стал привычной частью мира IT-технологий. API (Application Program Interface) – программный интерфейс приложения, это определенный набор протоколов, подпрограмм и инструментов для создания программных приложений. API должен упрощать работу программистов и облегчать разработку определенного продукта.

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

Это можно показать на примере API-интерфейса Сбербанка. Если мне нужно перевести деньги другому человеку, оплатить какие-то счета или сделать покупки – я могу воспользоваться клиентским приложением Сбербанк Онлайн. Но тоже самое я могу сделать через множество других клиентских приложений (программ). Они сделаны для удобства, я могу выбирать из всех приложений наиболее комфортное для меня.

Для программистов не составляет труда разработать эти приложения, для них предлагается API. Об этом свидетельствует, в том числе, доклад ЦСМС о том, что ЦСМС автоматизировал выдачу электронных ветеринарных сертификатов через ЭПЖ при прибрежном рыболовстве. Наверное, при этом воспользовались API-интерфейсом ИС «Меркурий».

Работать с хорошим API легко. Можно представить себе, как 20 лет тому назад мы заказывали создание Веб-сайта. Это было целым событием и организационно, и финансово. Теперь в каждой организации, да что там, в каждой семье есть школьник, студент, который создаст вам страничку в интернете.

Так и с API-интерфейсами. По мере их усовершенствования, работать с ними будет удобнее и проще.

Для чего нам нужен API-интерфейс?

Теперь обсудим, что это нам дает и как должен быть организован процесс информатизации в отрасли.

Росрыболовству нужно позаботится о хранении отчетности, которую им направляют с судов, РПУ, предприятий. Для этого они могли бы заказать разработку API-интерфейса, установить где-нибудь или у себя сервер базы данных и поставить сотрудников около сервера (5 человек хватило бы с лихвой) чтобы они следили за тем, чтобы сервер получал электроэнергию и работал. За качество отчетности отвечает API, так зачем держать целый Центр? Да ещё и филиалы! Это уже не модно.

На основе API-интерфейса десятки разработчиков-программистов, которые работают на предприятиях рыбной отрасли или рядом с ними, легко, с удовольствием и бесплатно разработают для этих предприятий десятки программ, электронных промысловых журналов, подсистем регистрации прихода-отхода судов, выписки электронных ветеринарных сертификатов, и проч., и проч. (см.рис.1). Они лучше других знают специфику флота, они работали для этих предприятий, они – профи. И они знают, что для каждого типа судна и вида промысла свои условия и понятия простоты и удобства.

Рис. 1

Так происходит во всем мире, в других отраслях нашей страны, например, в банковской сфере. И если Сбербанк не сделает API, не сделает бесплатное и удобное приложение Сбербанк Онлайн, клиенты уйдут в другой банк.

А если Росрыболовство, Россельхознадзор, Минтранс не сделают бесплатный и удобный API-интерфейс для своих ИС? А если Росрыболовство будет упорно тестировать и внедрять, тестировать и внедрять одну программу ЭПЖ из ЦСМС? То, что? Мне кажется, что процесс информатизации отрасли замедлится, как минимум.

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

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

А раз есть санкции, то должен быть объективный и надежный механизм фиксации нарушений. В случае автоматизированных информационных систем это не всегда просто сделать. Проблемы со связью, интернетом, «падением» серверов и прочими обстоятельствами приводят к задержкам в представлении отчетных данных. Происходит это не по вине отчитывающегося. Из-за проблем самих ИС в случае ИС «Меркурий» возникают задержки обработки и транспортировки продукции, в случае оформления отхода судна — ещё большие потери и нервотрепка.

Чтобы избежать этого, в состав API-интерфейса должен быть включен полный аудит представления отчетности. Если пользователь сформировал и направил отчетность, но из-за каких-то сбоев ИС не может принять его данные, то он должен следовать известному (опубликованному) четкому порядку, предусмотренному для таких случаев. Разумеется, что пользователь не должен никому доказывать отсутствие собственного нарушения.

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

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

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

Если отчетные данные, направленные в ИС прошли проверку и внесены в базу данных, то задача представления отчетности решена, пользователь ВБР получает уведомление, что его отчет принят.

Могут ли в этом отчете содержаться искажения, в том числе не умышленные? Конечно!

Но теперь с этим уже будут разбираться контролирующие органы и, если обнаружится, что выловили и отгрузили не 200кг, как записано в ССД, а 2 тонны камчатского краба (а выяснится это после того, как будут сравнены цифры промыслового журнала и ССД с фактическим объемом продукции на борту), то … это тема другого исследования.

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

При наличии API-интерфейса персонал, обеспечивающий работоспособность ИС, может не оказывать коммерческих услуг пользователям ВБР. Им же от этого легче. Их задача разработать качественное программное обеспечение API-интерфейса, на основе которого уже сами рыбопромышленники со своими программистами сделают удобные приложения. И такие бесплатные! приложения уже есть (см., например, рис.2).

Подводя итог можно сформулировать предложения следующим образом:

1. Исключить навязывание рыбопромышленникам каких-либо программ и платных услуг. Рыбопромышленники сами вправе выбирать пути решения задачи представления отчетности так, как это делают сегодня капитаны судов, пользуясь для этого различными программными средствами составления ССД. От добавления в ССД показателей пооперационного вылова и некоторых других показателей затраты, которые несет судовладелец, не должны увеличиться.

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

А пока достаточно разместить сервер БД ОСМ в каком-нибудь надежном дата-центре (ЦОДе), написать API-интерфейс и дать возможность программистам всех регионов и предприятий подключить уже написанные удобные приложения промысловой отчетности, ветеринарных сертификатов, регистрации отхода судов и прочее.

Рис. 2

И сразу нужно сделать предупреждение всем умельцам придумывать скидки и продавать товары по «черным» вторникам и пятницам: использование API-интерфейса к БД ОСМ и базам данных других государственных информационных систем должно быть бесплатным.

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

4. Принимать и вводить в действие руководящие документы, касающиеся нормативного, информационного, программно-технического и финансового обеспечения информационных систем, работа с которыми является для рыбопромышленников обязательной, следует после согласования этих нормативных актов с представительством рыбопромышленников — Российским союзом работодателей-рыбопромышленников. В процессе обсуждения содержания этих документов будет выбрана согласованная стратегия развития ОСМ. Менеджеры не только приедут и расскажут о том, что они хотят сделать, но и послушают специалистов в данной области. И каждый будет заниматься своим делом.

Заведующий кафедрой ИС КамчатГТУ,
Президент Ассоциации «Малых и средних рыбопромышленных
предприятий Камчатского края»,
д.т.н., профессор И. Г. Проценко