Черная дыра или не в коня корм

Share

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

Следите за руками:
Ассоциация народных волонтеров Украины (АНВУ) в октябре 2014-го года собралась с силами всех волонтеров и затолкнула в МО Волонтерский десант (ВД). Причем David Braun с товарищами еще и организовал фонд оплаты труда этого самого десанта. И часть людей 3 года получают кроме зп из бюджета еще и доплату из фонда. Причем люди-то трудятся. Кроме них трудится еще туча людей, не оформленных в ВД, а получающих зп в своих фирмах и конторах, которые таким образом косвенно спонсируют эту самую волонтерскую помощь (я не хочу разбираться, кто, чего, сколько и от кого получал, поверьте, это огромные деньги, которые прямо или косвенно вливались в создание этой системы).

Перед тем в МО проник Yuriy Husyev, и без него, конечно же, никакие такие труды организовать не получилось бы вовсе. Как он туда попал и каких усилий это стоило, я не знаю, но оно того стоило. Возможно когда-то об этом расскажет, например, Юрий Бирюков.

А еще я помню об одной тайной вечере, на которую мы с Алексей Гармаш (Alexey Garmash) попали практически случайно, и там пытались убедить Виктор Пузанов, Oleksiy Skrypnyk, Гусева и Арахамию в том, что нужна система контроля выполнения заявок от бойца на матобеспечение. Так чтоб вот прям пока в руки к бойцу амуниция не попадет, заявка бы не закрывалась и сигнализировала о том, что боец голый-босый, и кто-то в цепочке поставок не работает. Но если уже закрывалась, то все-таки можно было бы проконтролировать, чтоб боец эту амуницию никуда не девал (я очень люблю детскую поэму про осьминожек, там есть гениальная фраза «кого ни разу не кормил, в кого 15 ложек влил»). Леша даже написал подобие концепции такой системы. А я, как саповский консультант с многолетним стажем, конечно же тыкала SAP. Потому как изобретать велосипед зачем? Пузанов же говорил, что SAP дорог и надо применить решение из какой-то логистической конторы.

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

Вы еще раз не поверите, но система была создана и даже дотолкана до состояния пилотного проекта в 2 бригадах. Т.е. действительно, система умеет выполнять все функции, когда на каждого бойца заказывается положенная ему по нормам амуниция, если ее нет на складе роты-бригады-сектора-центральном, то ее закупают, а при выдаче боец специальной ИД-карточкой подтверждает получение.
________________________
Комментарий от Олег Точенюк: “Проект пилотом по факту пошел в одной бригаде и одном центре вещевого обеспечения (ОЦВЗ). Вторая бригада, не дали денег на покупку планшетов 🙂 поэтому там даже конь не повалялся к сожалению”.
________________________
Ну а дальше — вы как раз поверите. Работающая система лежит на полочке, разворачивать роллауты по другим бригадам никто не собирается, и более того, пилотный проект тоже сворачивается, т.к. носители знаний в пилотных бригадах демобилизуются.

Далее прилагаю описание системы и ее истории от одного из разработчиков, Олега Точенюка.
Да, и еще. В данном случае МО сожрало и не поперхнулось двухлетнюю работу 2 команд разработчиков, оплаченную из фонда ВД и работодателями разработчиков, или неоплаченную вовсе.
________________________
Комментарий от Олега: “Я бы не сказал, что все так уже и сворачивается, просто проект находится в подвешенном состоянии, дальнейшее его развитие по факту стоит, как и вопрос с тиражированием и дальнейшей поддержкой”.
________________________

Для справки.
День работы саповского консультанта может стоить от 200 до 450 евро. День, не месяц. Месяц работы самого захудалого программиста, который умеет писать работающие (!) приложения может стоить от 1000 до 5000 евро. Так что можете прикинуть, сколько это в деньгах.
САПовские лицензии, как и сервера у МО были с незапамятных времен, сколько за них было заплачено расследовали в свое время Наші гроші (Oleksa Shalayskiy).

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

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

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

Так как у ВСУ был уже купленный ранее SAP, а я лично кроме него уже давно ничего другого не знаю, да и компания изначально собиралась под реанимацию этой системы, то почему бы и нет. Из возможных решений данных задач было два варианта, использовать стандартную SAP ECC или использовать SAP ECC + отраслевое решение для военных. Со вторым вроде как красиво, но очень дорого. Скажем так, оплата этого расширения, будет измеряться в десятках миллионах американских президентов, что по моему личному мнению довольно дорого, ну это я со стороны налогоплательщика считаю, что эти деньги лучше все же потратить на другие военные цели, ну и с другой стороны, я опять же считаю, что эффект от ведения учета не должен быть равен стоимости ведения учета без введенной системы, хотя тут конечно же есть варианты 🙂. Поэтому, было выбрано стандартное решение SAP ECC которое было донастроено и доработано для решения поставленных целей.

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

1. Создание инструмента точного планирования вещевого обеспечения.

С текущим планированием в ВСУ для вещевого обеспечения, если послушать службу тыла, то все если не отлично, то точно хорошо. Почему так? Ну потому что все у всех есть, в смысле информации, другой вопрос качества этой информации, но это лучше не проверять, так как будут проблемы. Ведь как оно планируется. Если на пальцах и быстро, то у нас есть нормы + 10%, на всякий случай. И вот с нормами возникают проблемы, потому что они были рассчитаны на 18-20-летних призывников, а не на мужиков за тридцать, которые пришли и не влезли по этим нормам, так как они может и были в тех размерах в свои 18, но явно не сейчас. Поэтому, первое что было сделано, это создана структура ВСУ в системе со всеми штатными должностями (для пилотной/тестовой зоны, т.е. бригада + центр обеспечения). К каждой штатной должности, если она закрыта присвоен человек, который ее занимает. Далее для каждого человека при внесении внесены параметры, типа рост, вес, размеры всего что на него можно одеть и т.д. и так же к человеку присвоены утвержденные нормы обеспечения, которые ему полагаются при занимании данной должности. Таким образом, мы получаем полный набор вещевого обеспечения, который должны выдать военнослужащему с учетом соответствующих размеров. Сами нормы так же включают в себя не только вещевой набор, но и срок на который они выдаются. С другой стороны к каждому военнослужащему присвоен набор уже полученных вещей со сроками их использования, так называемая форма 45. Таким образом, задав плановую дату на основании, что есть у каждого военнослужащего + что ему положено из присвоенных норм, можно получить полный набор всех необходимых вещей в разрезе размерных сеток, которые необходимо поставить в часть для закрытия вопроса с вещевым довольствием. Планирование может быть выполнено как с самого верхнего уровня структуры ВСУ, так и с любых нижестоящих уровней. Этим мы закрыли вопрос с точным планированием.

2. Создание системы учета и контроля за складскими запасами по вещевому обеспечению.

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

3. Создание системы контроля по выдаче вещевого обеспечения.

Если послушать службу тыла, то все одеты, если послушать волонтеров и не только волонтеров, то все раздеты (уровень раздетости конечно меняется, но в целом картина одинаковая), короче чтобы решить данный вопрос, была реализована персональная схема подтверждения военнослужащими факта получения вещевого обеспечения. Реализовывалось это следующим образом, каждому выдавалась персональная карта с PIN-кодом, который знал только получатель. При получении, сержант ВМЗ или кладовщик должен был выполнить ввод документа о выдаче в систему, но провести/сохранить такой документ он не мог, система требовала подтверждения ввода картой NFC + ввод PIN-кода. При этом так же контролировался процесс какой картой пытаются выполнить подтверждение, т.е. система проверяла, что если выдача выполняется на табельный номер ХХХ, то должна быть использована карта, присвоенная данному табельному номеру/человеку. Конечно, никто не запретит старшему по званию сказать, эй солдат подь сюды, давай мне свою карту и скажи PIN, но это уже вопросы к военной прокуратуре, а не к системе, аналогично вас могут остановить нехорошие люди возле банкомата и предложить сделать то же самое с вашей банковской картой. А тут суть заключается в том, что я тебе выдал, ты подтвердил, что это получил, далее это сфера твоей ответственности куда ты дел эти берцы, тебе их выдали. Опять же при выдаче происходит автоматическое обновление формы 45 и мы всегда имеем полную картину, что, сколько и кому было выдано и до какого числа. Фактически это on-line пополнение данных для планирования вещевого обеспечения.

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

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

4. Обеспечение максимальной оперативности при построении любых отчетов по состоянию вещевого обеспечения.

Имея штатную структуру, имея полный набор заполнения штатной структуры, зная оперативно что и кто когда получал, форма 45. Зная запасы на всех уровнях вплоть до ротных каптерок, построить все необходимые отчеты, с ответами на вопросы, где, что, сколько, когда и кому не представляется проблематичным, доработка тут заключалась только в возможности группировки данных в разрезах номенклатуры из норм обеспечения. А ну и еще формы РЕЧ1-6, святое службы тыла, куда же без этого. Суть всего этого заключается в том, что имея исходную централизованную базу и необходимую детализацию данных, можно всегда построить необходимые отчеты в необходимых разрезах. А если учесть, что 90% информации должно было вноситься в момент возникновения физической операции, то достоверность данных была соответствующая. Фактически могли быть задержки только с информацией от сержантов находящихся со своими подразделениями на передке, но и там оценивали задержку в недели.

5. Создать инструмент отслеживания всех заявок по вещевому обеспечению, а так же их выполнение. Хотя данный пункт пересекается по большому счету с предыдущими по планированию и контролю и учету, в целом идея заключалась в том, что все перемещения и выдачи имеют в своей основе начальный документ. Например, базовой была заявка на выдачу необходимых вещей конкретному военнослужащему, далее на основе этих заявок создавалась групповая заявка объединяющая заявки рот на следующий уровень и таким образом на уровень начальника службы вещевого обеспечения поднималось 5-8 групповых заявок, который он уже в свою очередь, что-то выдавал, что у него было на бригадном складе, а все что отсутствовало поднималось на региональный центр обеспечения и там в свою очередь имелись консолидированные заявки от бригад. При этом любую такую заявку можно было развернуть вплоть до человека. Заявки имели все кучу атрибутов определяющих срочность ее выполнения, поэтому в условиях дефицита, проблемы кому выдавать, а кому нет, так же не должно было стоять. В целом задача стояла такая, что не нужно вешать телефоны доверия и т.д. в каждой части и рассказывать что солдат редиска, потому что он не позвонил и не доложил, а на самом деле виноват его начвещь, который не подал вовремя заявки и т.д. В этой реализации, кто не подал заявки видно и без звонка, так что улучшить вещевое обеспечения система конечно же не могла, но по крайней мере навести порядок и указать на крайнего, это вообще без проблем.

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

Из планов далее, вообще, это даже не вопрос сформировать централизованный расчет зарплаты всем военнослужащим, так как общая база ВСУ уже была бы в системе. Учет ГСМ, не вопрос… да и вообще много чего было бы не вопрос. Да проблемы с разделением полномочий и кому что видно, это тоже решалось и знаете бундесвер это как-то устраивает 🙂

Какой итог, ну насколько я знаю ведение на уровне бригады умерло с дембелем последнего поддерживающего это дело + безопасность проснулась со своим «все плохо, это не безопасно, это…» короче как обычно. Вроде как живет на уровне одного центра обеспечения, но надолго ли?! Я не знаю. Если бы дали это дальше делать, то нужно было докрутить вот те 20% и тиражировать это сначала на центры обеспечения, а далее и по бригадам. Пару лет это наверное заняло бы, хотя все зависит конечно от команды, нас там всего было то раз-два и обчелся.

Ольга Лугова стаття

Share

Висловіть свою думку

Google+