Архітектурні комітети, налагодження тестування та “інфраструктура-космодром”. Як відбувається ІТ-трансформація Держмитниці

ІТ-процеси є не лише в бізнесі. Вони є і в державному секторі. Редакція DOU вирішила розібратися: у чому різниця між роботою в бізнес-структурі та державному органі і чи є вона взагалі? І що мотивує ІТ-фахівців працювати на державу?

Ми поспілкувались з Євгеном Єнтісом, радником з ІТ-трансформації «Нової митниці» та фактично керівником реформи в ІТ-структурі Державної митної служби України, про те, як відбувається діджиталізація системи, хто стоїть за змінами та що чекає на митницю найближчим часом.

Дисклеймер: стаття написана до призначення нового виконувача обов’язків голови Держмитниці.

Далі — розповідь Євгена.

Спершу поясню, як заплановано реформу «Нова митниця» в ІТ-відділі. В департаменті ІТ працює наразі 62 фахівці у двох управліннях та чотирьох окремих відділах: розробки, адміністрування розробки, супроводження програмного забезпечення, телекомунікацій (адміністрування мереж і сервісів). На сьогодні майже всі спеціалісти підтримують внутрішні проєкти, вони не займаються розробкою нового функціоналу. Але найближчим часом я планую залучати всіх охочих до нових проєктів.

Якщо говорити про позаштатних працівників, які, власне, творять реформу, то вони перебувають на донорському фінансуванні, що забезпечує ринковий рівень зарплат. Зараз таких посад 20. Проте основною мотивацією займатися реформуванням ІТ-системи митниці є амбіції та можливість бути в команді висококваліфікованих спеціалістів. Як доказ: завжди є охочі приєднатись до команди, але поки що шукаємо лише тестувальників.

У серпні 2019 року я зустрівся з Максимом Нєфьодовим, на той час головою Держмитслужби, він і запросив мене долучитись до команди. Тоді я працював у Prozorro і вже задумувався про зміну роботи: хотілося нових викликів. Я розглядав кілька пропозицій на роль консультанта з діджиталізації як у комерційному секторі, так і в державному. Проте раніше мав досвід співпраці з Максом і вирішив допомогти реформувати митницю. У команді тоді були лише техлід Максим Корженевський та власне Максим Нефьодов. Я ж взяв на себе організаторські функції, став розширювати команду. До кінця 2019 року ми зібрали її кістяк з 4 людей.

Ковель. Аналізумо ІТ-процеси

З чого почали реформу: аналіз ІТ-системи Держмитслужби

Наступним кроком став поверховий аналіз систем. Це не можна назвати аудитом, бо за законом його проводить лише Держспецзв’язок. Мені з командою було непросто отримати доступ до системи: довелось чекати три місяці, поки Мінфін через робочу групу з представників СБУ, Мінфіну, ДФС і Держмитслужби надав дозвіл (хоч і дуже обмежений). Ми навіть розглядали варіант видати постанову Кабміну за підписом тогочасного прем’єра Олексія Гончарука, бо ніхто не хотів, щоб ми проводили технічний аналіз ІТ-системи. До того зовнішні спеціалісти не отримували доступи. Останній аналіз зробила компанія Deloitte в червні 2019 року (всього фінансового блоку). Вона написала 420 сторінок документації, дуже поверхової та неконкретизованої, адже доступу до систем не мала.

Аналіз зайняв два місяці. Над ним і працювала новостворена команда: бізнес-аналіз — Роман Ланський, BA; телекомунікаційне та серверне обладнання — Артем Карась, архітектор високонавантажених систем; аналіз даних — Євген Копилов; архітектура — Максим Корженевський (техлід Prozorro) та Павло Жук, архітектор eHealth, раніше працював у Facebook.

У результаті написали звіт «айтішним жаргоном», за який Мінфін ще довго «цькував» усю команду. Та важливіше те, що висновок звіту засвідчив: чинну систему АСМО «Інспектор-2006» неможливо модернізувати. Її створили ще у 2003-2006 роках на стеку Microsoft. Вона є архітектурно розподіленою: на комп’ютерах встановлювали ПЗ, що під’єднувалося до локальних баз, а локальні бази синхронізувалися з центральним сервером. Оскільки на той час виникали проблеми з інтернет-каналами, це було необхідно. Наразі ж система вразлива, є ризик крадіжки баз даних.

І це не єдина проблема. Відсутність нормального тестування, документації, повноцінного логування та моніторингу систем, відомостей, де лежить код і як отримати до нього доступ, унеможливлювала стабільність і безпеку. Та найважливіше: вендор-лок підтримують 1-2 внутрішніх розробники, що мають прямий доступ до продуктивної системи, тільки вони знають, як вона працює.

Єдина автоматизована інформаційна система (ЄАІС), у межах якої діє «Інспектор-2006», має більше даних, проте все одно її модернізація неможлива: через відсутню документацію, застарілі технології та архітектуру.

Структура ІТ-команди

Команда спроєктувала архітектуру нової системи та поділила командні ролі. Вийшла cross-delivery team: CTO, Tech Lead, UX/UI дизайнери, Business Analysts, Product Owners, DevOps та команда окремих стримів:

Customs.Back — те, з чим будуть працювати фахівці митниці під час митного оформлення;
Customs.Front — інтерфейс взаємодії під час митного оформлення, зокрема адміністративні послуги, митне оформлення та взаємодія з органами під час отримання дозвільних документів. Те, з чим будуть працювати декларанти та контролюючі органи, наприклад, «кабінет користувача» і «єдине вікно» для зовнішніх спеціалістів;
BIRMA — стрим ризиків, аналізу даних за допомогою BI, інтеграція із зовнішніми системами та відкриті дані;
international: транзитна система NCTS, AEO, обмін інформацією та взаємодія з іншими країнами.

PO разом із BA кожного зі стримів формує бачення системи, спілкується зі стейкхолдерами, проводить аналіз, формує концептуальне бачення свого стриму, усуває зайві процеси, розробляє технічне завдання, запускає та супроводжує розробку систем. Є техліди, тестувальники, розробники, UX/UI, техрайтери, девопси. Усього в ІТ-напрямі працює близько 40 фахівців. Формат співпраці з розробниками — і аутсорс, і аутстаф.

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

Процес розробки

Перший етап, без якого розробка за кошти донора не може розпочатись, — створення робочого плану для затвердження донором. Потім треба підготувати Concept Note — високорівневий документ, який підписують донори, фінансисти та технічні спеціалісти з його боку. Потім відбувається акцептування: Держмитслужба надає лист, що розробка цього продукту є необхідною. Тільки після цього пишуть технічне завдання, яке проходить внутрішнє погодження ДМСУ. На цій основі складають лист до донорів і у разі схвалення оголошують закупівлю.

Наступний крок — розгляд і підписання договору, створення календарного плану розробки. Опісля — здавання проєкту та акцептування в ДМСУ, зрештою взяття розробки на баланс. Весь процес від етапу формування потреби до підписання договору займає від 5 до 7 місяців. Тому ІТ-реформу не вдається провести так швидко, як би хотілося.

Після однієї з презентацій у Мінфіні. На фото: Роман Ланський (зліва), Євген Єнтіс (за столом), Сергій Кулик (справа)

Такий тривалий бюрократичний процес зумовлений потребою залучати донорські кошти. Держбюджет не виділяє грошей, натомість існує фінансування від Public Finance Management Support Programme for Ukraine (EU4PFM). Крім того, Максим Нефьодов зміг залучити кошти The USAID/UK project Transparency and Accountability in Public Administration and Services (TAPAS) та The USAID project Competitive Economy Program (CEP).

За процес розробки відповідають PO і BA. Працюємо за Agile, спринт триває тиждень, оскільки є потреба бачити результати швидко. Всі завдання ведуться в Jira, ми її модернізували, додали купу плагінів. Наприклад, на кожне завдання є definition of done. Загалом команда має виконати 20 завдань DoD під час здавання розробки, а саме:

Документація:

нормативне технічне завдання;
BPMN-діаграма(и) з описом процесів/бізнес-логіки;
детальна L2/L3-топологія системи у вигляді діаграм (якщо є потреба);
інструкція з розгортання, оновлення та відновлення системи;
схема потоків даних + структура бази даних + ER-діаграма;
функціональний опис системи;
інструкція адміністратора та користувача (кожна роль) системи;
програма та методика комплексних випробувань;
протокол комплексних випробувань.

Технічна частина:

Helm charts та/або Ansible-плейбуки на розгортання, оновлення та відновлення системи;
автотести (мінімум 85%) + протоколи тестування;
Unit-тести (мінімум 90%) + протоколи тестування;
стрес-тести + протоколи тестування;
навантажувальні тести + протоколи тестування;
політики та процедури SDLC у вигляді магістралей (pipelines) у Gitlab CI/CD із використанням GitLab Runner;
код у Gitlab;
коментування коду для показу у Swagger;
логування роботи системи та отримання логів у центральній системі з використанням ELK-стеку;
моніторинг роботи системи та надсилання інцидентів у месенджер.

Від розробників очікують активного коментування коду, логування, ведення документації для того, щоб у разі потреби інші могли швидко підхопити проєкт і вести його далі. Це необхідно робити, хоч через це вартість проєкту зростає. Також вимагають перевірку на вразливості, проведення функціональних тестів, навантажувальних тестів тощо — об’єм покриття ними має становити близько 90 відсотків. Код зберігається у внутрішньому GitLab, уся розробка відбувається тільки там. Це одна з основних вимог.

Налаштували повноцінні CI/CD-процеси. Баги, якість коду та можливі вразливості аналізує автоматично один з пайпланів. Найближчим часом плануємо побудувати процес QA.

Щотижня проходить архітектурний комітет за участі всіх чотирьох PO та техлідів стримів, адже у розробці всі проєкти перетинаються і часто зміни залежать одна від одної. За два дні до засідання команда узгоджує план і питання, які виноситиме на обговорення, щоб зустріч не тривала 3-4 години і не складалася лише з «технічних» розмов. Всі складні технологічні рішення ухвалюють саме на цих зібраннях за активним обговоренням. Останнє слово залишається за головним техлідом Максимом Корженевським. Він каже, що ці розмови — одні з найскладніших, найбільш інтелектуальних за всю його кар’єру, а порівнювати є з чим, він мав досвід роботи у міжнародних банках і компаніях.

Якщо порівнювати з інфраструктурою Prozorro, то у митниці вона складніша: це Kubernetes з усіма «плюшками» — наскрізним моніторингом, логуванням, брокерами гарантованої доставки повідомлень, що схоже на космодром. Уся документація та протоколи розробляються та зберігаються в Confluence, щоб у разі змін нічого не втратити та не створювати вендор-лок.

Ключові проєкти

Наразі ІТ-напрям запустив та допрацьовує кілька основних проєктів.

Онлайн-калькулятор вартості митного оформлення авто

Сервіс підтягує дані щодо мінімальної, середньої та максимальної вартості вказаного авто на основі реальної інформації моделей машин за історичними даними митниці. Це не інноваційний інструмент, на ринку такі калькулятори давно існують. Однак він необхідний: є потреба показувати статистичні дані під час оформлення автомобілів. Процес розробки зайняв два місяці. Усю розробку можна переглянути тут .

Онлайн-система скарг на роботу Держмитслужби

Після створення митниці постало питання опрацьовувати скарги. Оскільки на той час у Держмитслужбі не було готового рішення, запропонували зробити доступний інструмент. Коли митниця і податкова роз’єднались, кол-центр перейшов до останньої. Митниця домовилась із Дмитром Дубілетом про загальний проєкт з єдиного кол-центру, що приймав би скарги та звернення щодо служби. Ми розробили власний софт, тепер скаргу можна подати онлайн. Усю розробку можна переглянути тут . Також доступна аналітика щодо скарг.

Customs.Front та «єдине вікно»

Проєкт TAPAS із розвитку механізму «єдиного вікна» профінансувало Агентство США з міжнародного розвитку (USAID). Проєкт іще в розробці, очікуємо його завершення у вересні-жовтні. Це «вікно» по суті є кабінетом декларанта й дає можливість самостійно подавати декларації. Архітектура системи передбачає можливість інтеграції з іншими державними реєстрами та сервісами. Вони відбуваються на рівні обміну стандартизованих пакетів даних з бекендом взаємодіючих систем і реєстрів.

Розробку віддали на аутсорс, але через чутливість внутрішніх процесів залучили PO і двох BA. Ми продемонстрували готовий функціонал керівництву митниці та Мінфіну: авторизацію з id.gov.ua , подачу заяви на отримання брокерської ліцензії та інші адміністративні послуги. А ще частково показали, як подавати декларацію на авто. І почали інтеграцію з ЄДР для автоматизації заповнення великої кількості інформації в заявках (наприклад, заповнення заявки на брокерську ліцензію буде повністю автоматичним). Розробляємо з використанням Angular 9, Java 11, Kafka, PostgreSQL 12.

Функціональна схема модулів ІТС Customs.Front

BI-система

У квітні 2020 року ми запустили аналітичний інструмент зі статистичних даних Держмитниці з товарообігу: обсяги імпорту та експорту України з будь-якою країною та щодо будь-якого товару (читати детальніше ).

Ідея проєкту — дати можливість працювати з актуальними даними в режимі 24/7 з використанням сучасних інструментів аналізу. Бізнес і спільнота чекали на цей інструмент десятиліттями, адже до впровадження рішення необхідно було вручну зібрати дані, нормалізувати, підібрати рішення і лише потім починалася робота з аналізу даних, трендів під задачі бізнесу. У гіршому разі база митниці просто «купувалась на Петрівці».

Перший реліз дав позитивні відгуки від бізнесу з Норвегії, Чехії, Тайваню та України. За нашими останніми даними, ВІ надає сервіс 500 користувачам щодня, і це практично без потужного промоушену. Такий фідбек користувачів мотивує розвивати цей сервіс і далі. Проте зараз це, на жаль, на паузі — необхідне погодження Держмитслужби та фінансування.

Автоматизована система управління ризиками

Одним із найважливіших елементів функціонування митниці є виявлення порушень законодавства у процесі оформлення митної декларації. АСУР дає змогу прискорити митне оформлення товарів завдяки вибірковості митного контролю — митні органи концентруватимуть увагу на найбільш ризикових зовнішньоекономічних операціях.

Для ефективної організації роботи з ризиками з погляду захисту держави (надходження, заборонені перевезення та інше) та бізнесу (прозорі та єдині правила проходження митниці для всіх СЗЕД) потрібно було перебудувати наявну систему «Інспектор». Це, своєю чергою, сприяло створенню нової системи АСУР 2.0, що дає можливість митниці керувати ризиками без або з мінімальним залученням ІТ-спеціалістів.

Крім цього, закладено архітектуру ієрархічного доступу до системи, де всі дії фіксуються. І це лише перший крок, далі плануємо впровадити новітні методи оцінювання та управління ризиками, а також застосування технологій машинного навчання.

Вебпортал

Спершу провели маркетингове дослідження за участі різних груп користувачів і розробили дизайн-портал. Він створений на Python 3.6, PostgreSQL, 10 HTML5, CSS3, jQuery, Nginx. CMS має допрацьований під потреби UI — кросплатформову та відкриту систему Odoo (версія 13). Її підтримка безкоштовна, а можливості для подальших доробок — необмежені. Є інтеграція з Google API, функціонал для людей із порушенням зору, Elasticsearch. Розробка разом з дослідженням почалась у середині березня і закінчилась на початку червня.

Мапа митної інфраструктури

Сервіс показує актуальний стан і детальні паспорти всіх пунктів пропуску, місць митного оформлення, місць міжнародного поштового обміну, сортувальних станцій із можливістю аналізувати цю інформацію функціоналом мапи. Мапа — це реєстр для усіх цих типів локацій, що є частиною запланованої ІТ-системи. Розробка: Vue, PHP. Зараз заповнено майже 100% інформації.

Плани та перспективи

Найближчим часом, окрім допрацювання вищеперелічених проєктів, команда зосередиться на таких ключових моментах.

Оптимізація серверів. На початку реформи системи запускали на серверах митниці. Тоді ж система почала працювати нестабільно, як виявилось, через недосконалість інфраструктури. Через відсутність моніторингу і логування неможливо було оперативно реагувати на інциденти. Сервіс перенесли в Amazon і за півтори години заново розгорнули всю систему, підняли моніторинг і логування, побачили помилки і виправили їх. І зрозуміли: інфраструктура митниці не підготовлена до нових викликів.

Цього року ми придбали послуги дата-центру, що надав інфраструктуру, в якій ми розмістили ландшафт, ПЗ, сервіси. Зараз ведемо перемовини, щоб отримати дозвіл розгортати все в інфраструктурі Мінфіну. На це є щонайменше дві причини: хороша інфраструктура та підпорядкування митниці цьому органу.

Також на розгляді парламенту закон про хмарні послуги, що може внести корективи у діяльність ІТ-систем і допоможе зняти останні бар’єри в розміщенні даних державних органів.

Розробка. На листопад-грудень 2020 року запланували створити ядро системи, кабінет та нову систему ризиків АСУР для митного оформлення і поступово додавати новий функціонал. Щодо Customs.Back, то наразі триває робота над створенням оновленої системи АСМО 2.0 (Customs.Back), що прийде на заміну АСМО «Інспектор-2006» та ЄАІС. Впровадження АСМО 2.0 буде відбуватись поетапно, починаючи від окремих груп товарів (автомобілі в режимі імпорту) до покриття усієї номенклатури товарів у режимах імпорту, експорту, транзиту. Найближчим часом плануємо реліз і тестування «кабінету інспектора», «журналу пункту пропуску» та фінансового модуля.

Інформаційна безпека. Наразі всі зміни в систему відбуваються через Git, а розробники не мають доступу до продуктового середовища. Мета — впровадити повноцінне логування та моніторинг. Логи не повинні модифікуватись, а у продуктове середовище має входити мінімум людей. Плануємо запустити тестування на вразливість і проєкт з білого хакінгу за досвідом Prozorro. А також побудувати Security Operations Center для оперативного реагування на кіберінциденти та захисту інформації.

Відкриті дані. Завершили основну розробку щодо відкритих даних для проведення експортно-імпортних операцій. Сам сервіс — DWH та API із документацією на базі Swagger і відмовостійким кластером БД на базі MongoDB. Держмитслужба має врегулювати нормативні питання: внести зміни в постанову № 835 та затвердити порядок роботи сервісу. На жаль, розробка вже «лежить» близько двох місяців. На мою думку, ніхто не хоче відкривати дані. Потрібно бачити динамічні дані, щоб уникнути махінацій, з якими митниця і має боротись. Тож щоб розв’язати це питання, доводиться багато дискутувати та доводити органу переваги відкритих даних.

«АСМО 2.0. Пошта» . Щороку в Україну надходить 30-40 мільйонів посилок, проте Держмитслужба не знає точної цифри. Супровід процесу оформлення більшості з них відбувається лише на папері, автоматична система ризиків не застосовується. Тривають перемовини з «Укрпоштою». Ми почали досліджувати процеси та проєктувати інтерфейси для інтеграції.

Фото з робочої зустрічі з представниками «Укрпошти» щодо інтеграції систем

Проблеми

На мою думку, найбільша проблема — відсутність взаємодії та боротьба зі штатними розробниками. Вони не розуміють, для чого створювати нове, якщо старе і так працює. А для нас основним є прозорість, документування, тестування та дотримання світових найкращих практик і вимог. Тому, на мій погляд, вони й не йдуть на співпрацю.

Також для успішної реформи потрібні люди, які добре розумітимуть процеси в митниці та разом з нами впроваджуватимуть нові проєкти. Для зменшення ризику недостатнього розуміння процесів ми активно занурюємось у це: формуємо фокус-групи, їздимо і спілкуємось з людьми на місцях, розповідаємо про реформу.

Серед помилок можу назвати поспіх. Наприклад, уже під час демонстрації нашого бачення декларації ми дізналися, що є міжнародні стандарти, яким вигляд декларації суперечить. Довелося повертатись, розбиратись, вчитись. Звісно, за активної участі профільних фахівців-митників процес був би простішим. Сподіваюсь, найближчим часом це налагодимо.

ІТ-фахівці «Нової митниці» про свою роботу

Редакція DOU також запитала у Product Owner’ів напрямів та бізнес-аналітиків про те, як потрапили в ІТ-команду «Нової митниці» та чим займаються на своїх посадах.

Сергій Кулик, PO на митниці із січня 2020

До митниці я запускав проєкт «Прозорро.Продажі» в ролі CTO/PO/BA — фактично one-man-it-army. Зараз серед моїх робочих обов’язків управління Customs.Back (бек-офіс) — внутрішньою системою, що приходить на зміну наявним рішенням. У новій системі будуть працювати відділи ДМС України, що залучені в процеси митного оформлення. Найскладніше у роботі — застаріла нормативна база. Вона зі скрипом натягується на сучасні бізнес-процеси та технології.

Мені подобається працювати у «Новій митниці»: тут є команда з величезним досвідом у найрізноманітніших сферах бізнесу/gov/реформ, нові технічні рішення, постійний драйв. Люблю field trips на місця митного оформлення або в пункти пропуску. Таким чином ми збираємо вимоги до нової системи та визначаємо потенційних союзників. Насправді є багато людей, що прагнуть змін на митниці, але їх або не чують, або вони перебувають у тіні більш гучних, але менш — епітет за смаком — колег.

Володимир Чугай, PO на митниці з січня 2020 року

Раніше працював у бізнесі та менеджменті ІТ понад 10 років. Пройшов шлях від мережевого інженера до Head of Product у таких компаніях, як KM Core Holding, Crazy Llama. Успішно реалізував низку проєктів у телекомунікаційній, енергетичній та туристичній сферах.

Зараз я РО стриму BIRMA, це передбачає визначення, наповнення напрямів розвитку відкритих даних, Business Intelligence та системи управління ризиками, з якими стикається митниця від ідеї до впровадження під ключ та постімплементаційної підтримки.

Чому я вирішив творити митну реформу? Бо приваблюють масштаби змін країни, люди та можливість створити бенчмарк-сервіс, на який будуть рівнятись передові країни світу. Найскладніше у роботі — ментальність і нормативна база. Основний девіз — здоровий глузд у всьому.

Та хоч негативу і вистачає, хочеться розказати про позитив. Наші наміри — реформувати митницю в прозорий та легкий у користуванні сервіс з нотками емоцій. І тут кльово вписується задумка (гіпотеза) загорнути комунікацію з ІТ-сервісами митниці в зрозумілу форму через емоції КАПІБАРА (очікування платежу, помилки при оформленні декларації, успішне оформлення декларації). КАПІБАРА — це справедливий митний інспектор, який забезпечує рівні правила роботи для бізнесу, адміністрування надходжень до бюджету, він нетерпимий до різноманітних зловживань.

До чого тут звірятко? КАПІБАРА — це скорочення основних систем, які плануємо впровадити на митниці: CAbinet, Portal, International, Business intelligence, ASUR, RMS, mobile Automation. Воно збіглося з реальною назвою звірятка.

А так ми відпочиваємо :) На фото — Володимир.

Роман Ланський, Program Manager, відповідальний за створення нової ІТ-системи, на митниці з грудня 2019 року

Останні три роки лупаю скалу в держсекторі — МОЗ, eHealth, «еМалятко», Держфонд регіонального розвитку Мінрегіону тощо. До того, як вирішив ламати собі психіку, працював аналітиком в EPAM, «Новій пошті», «Укрсиббанку».

Моє завдання в «Новій митниці» — з ІТ-хаосу, що панує на митниці, створити нову систему, яка має стати світовим бенчмарком галузі. Фактично придумати філософію та візію роботи комплексу ІТ-продуктів, проєктувати бізнес-процеси та взаємодію цих систем, координувати роботу стримів. А ще, звісно, тонна операційки з підбору команди, фінансів, закупівель тощо, аби створити умови для реалізації реформи. І давати копняків усім навколо — від митників до інших міністерств, щоб команда могла рухатись уперед.

Головний виклик, як на мене, — це адвокація концептуальних змін. Митники — консервативна, сильна та монолітна спільнота, яка за 25 років уже тісно вплелася в чинний уклад митної справи. До того ж середній вік співробітників 40+, часом це теж впливає, коли ми говоримо навіть про дрібні інновації.

І зрушити цей пласт, впроваджуючи кардинально нові решення та відмовляючись від звичних усім — найважче. Навіть коли бенефіти від цього всім очевидні. Вражають масштаби катастрофи. А якщо серйозно, то мене драйвить масштабність і важливість результатів, потужні та ціннісні люди поруч, які неймовірно резонують.

Коли ми дивимось на корпоративні сервіси, то маємо вибір. Можемо користуватись або ні, є конкуренція, змога поскаржитись на сервіс. І його, найімовірніше, підправлять, щоб утримати свого клієнта. А митниця — обов’язковий сервіс, яскравий приклад репресійної суті держави, із яким щодня стикаються десятки тисячі громадян та працівників бізнесу. І зараз взаємодія із цим держсервісом — це квест із болю та страждання для всіх. Часто навіть для митників. На жаль, піти на альтернативну митницю неможливо, вона не зачиниться через погану роботу і її не поглинуть успішні конкуренти. Єдиний шанс щось змінити — це команда відчайдух, які готові, засукавши рукави, вигребти ці стайні.

І я отримую неймовірний кайф від усвідомлення того, що можна переломити це. Коли в кінці проєкту тисячі й мільйони людей не стикнуться віч-на-віч з усім чим трешем, коли «білий» бізнес буде в кращих умовах за «чорний» та «сірий», а збільшені доходи бюджету зможуть покрити потреби нашої соціалки.

Мені здається, що зараз не знайти в Україні місця, де можливо більше реалізовувати потяг до створення потрібних і важливих проєктів. Із таким масштабом і наслідками.

У мене дуже низька толерантність до корупції та неефективності. А величезна кількість людей тут — це символи цих явищ. Звісно, серед них є ті, що дотримуються доброчесних орієнтирів, але таких одиниці. Здебільшого митники або прямо причетні до «схем», або заплющують на це очі. Усе ж реформувати митницю без митників неможливо, адже вони є основним стейкхолдером процесу. І коли ти дізнаєшся про рахунки-яхти-закордонну нерухомість, то мати хоч щось спільне із цими людьми не дуже хочеться.

А коли звільнили Макса Нєфьодова, то залишитись і продовжити роботу було титанічно важко. Тому робота в такому середовищі — щоденний, важкий, моральний вибір. Але хто ж тоді буде це реформувати? Будь-хто із цінностями буде змушений цей вибір робити, іншого шляху немає. Є чітке розуміння, що якщо ми зараз програємо, то шанс на будь-яку реформу в митниці з’явиться не раніше ніж за 3-4 роки. Адже хто адекватний та сильний буде ризикувати йти сюди, якщо наша команда провалиться? Цей тиск — теж один із найскладніших моментів роботи.

Напевне, найсмішніше, з чим стикаюсь тут, — це заявки на елітарність. Наприклад, на початку проєкту, коли зайшли в нову локацію, знайшли статую Гермеса та чотири бурштинових картини! І це в колишній кімнаті для кейтерингу при конференц-залі. До речі, один із залів — із білої берези. Кажуть, це дуже круто, хоча я не експерт.

А їдальня на митниці... Ділиться на звичайну, «плебейську» та зал для директорів із гобеленами, різьбленими меблями та обслуговуванням. Хоча салат все одно «Десна»! А ще ніколи не втомлюєшся дивуватись професійно. Але то службова інформація.

Павло Шкурихін, PO на митниці з грудня 2019 року

Кілька років працював бізнес-аналітиком у бізнесі та разом з Романом Ланським півтора року створював «Централь103» — центральний компонент системи екстреної медичної допомоги.

На митниці обіймаю посаду РО напряму Customs.Front — системи, через яку зовнішні користувачі взаємодіятимуть зі службою. Подання митних декларацій, адміністративні послуги, реєстр прав інтелектуальної власності та багато іншого функціоналу буде доступно для користувачів через універсальний електронний кабінет. В новій системі також працюватимуть відділи органів ДМС, пов’язані з наданням різноманітних адміністративних послуг. А ще працівники тих ЦОВВ, яким необхідно обмінюватись з митницею дозвільними документами.

Ще під час роботи в МОЗ я збагнув, що мене тягне до труднощів та неординарних завдань. І митниця ними наповнена по вінця. Часом процес пошуку рішення схожий на блукання в лабіринті з купою тупиків. Трапляються ті, хто постійно вказує напрямок, але ще зрозумій, чи він правильний. Та досягнення мети того варте.

Чимала частина роботи в реформах — це аналіз і, так би мовити, взаємодія з нормативкою — постулатами, якими роками, якщо не десятиліттями, керуються у своїй роботі працівники державної служби. Найважче — будувати наші «космічні кораблі» та зберігати баланс здорового глузду і нормативних вимог. Тому зміни необхідні.

Можна багато розповідати про випадки, коли долоня мимоволі тягнулася до обличчя під час аналізу чинних процесів. Але тішать моменти, коли ваші уявлення про автоматизацію та розвиток системи збігаються з баченням працівників митниці. Або якщо вони хоча б дивляться в одному з тобою напрямку. Так, почуте з вуст одного керівника відділу: «Приберімо повністю перевірку заяв людиною, хай це робить комп’ютер», стало подією дня. Побільше б таких митників.

Максим Корженевський, Tech Lead

Я затятий айтішник, років з 16 кручуся в цьому. Зараз мені 40. Потрапив в українське IT після Майдану. Я, звичайно, припускав, як у нас тут, але працювати волів на Заході. І тут Майдан, ми на колінах робимо кілька IT-проєктів. Серед досягнень тих днів — ми винайшли IVR-капчу, щоб кол-центр працював, коли його «валили», передаючи скриптом DTMF-сигнал. Також придумали, як криптувати дані з планшетів, розуміючи, що вони можуть дістатися ворогові. Тоді ж знайомий запропонував долучитися до побудови ІТ-процесів у Prozzoro. Я йшов на Security Consultant, у результаті став техлідом.

Prozzoro — рай з єдинорогами та метеликами. В нас усе вийшло — geo distributed system, Infrastructure as a code, Open Source... Потім Макс Нефьодов покликав у митницю: велика, фінансово важлива система з великими корупційними ризиками. Нормальний такий челендж. Концентрація реформ, важливість системи і розуміння бенефіту для країни зашкалювали.

Драйвити все почала команда. Ви не уявляєте, які це люди. Вони всі молодші за мене, але я не про ейджизм, а про заздрість :)

У нас мультистек, Kubernetes, мікросерверна архітектура, потужний CI/CD, 20 пунктів у Definition of Done, шина на основі Message broker, тотальний моніторинг і логування. А ще хочемо розподілити все на кілька георознесених дата-центрів, створити нейронну мережу, що допомагатиме заповнити декларацію, і систему аналізу ризиків з купою data sources тощо. Одне слово, є над чим працювати.

Читайте також: Процеси за Scrum, білі хакери, аутсорс-розробники. Як працює ІТ-відділ ДП Prozorro

Опубліковано: 26/08/20 @ 10:03
Розділ Різне

SEO Блог