Інтерв'ю

Вячеслав Великодний : Автоматизація та реформування УЗ. Чого чекати клієнтам?

Вячеслав Великодний

заступник директора з питань інформаційних технологій Апарату інформаційних технологій Укрзалізниці

Які види діяльності Укрзалізниці вже автоматизовані, і які мають бути автоматизовані найближчим часом?

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

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

Тоді спробуємо їх розділити. Що вже робиться у внутрішньому секторі автоматизації УЗ і внутрішнього документообігу? Що планується зробити найближчим часом?

Зазвичай за такими запитаннями стоїть інше запитання – чи впроваджує компанія ERP-систему (Enterprise Resource Planning).

Тут потрібно дещо роз’яснити.

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

На залізниці немає чіткого поділу на виробничі цехи й заводоуправління, тому виникають два принципових моменти:

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

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

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

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

Таким чином виходить, що автоматизована система, яка реалізує технологічний процес перевезення вантажів, за великим рахунком, виконує значну частину функцій ERP-системи – прийняття замовлення, його виконання, проведення фінансових розрахунків з клієнтами й формування звітності компанії.

Звідси висновок, що на залізниці класична ERP-система розпадається на дві частини:

Перша – бізнес-процеси, пов’язані з виробничим процесом і відносинами з клієнтами.

Друга – бізнес-процеси, пов’язані з управлінською діяльністю центрального офісу компанії та його філій.

Ось ви згадували електронну накладну. Наскільки вона забезпечує захист прав та інтересів клієнтів у судах, у держорганах, у роботі з власними контрагентами?

Відповідь проста – цілком. Поняття «електронна накладна» виникло за рішенням Кабінету Міністрів. Було розпорядження 16 грудня 2009 року, де всім причетним держструктурам було доручено допомогти Укрзалізниці в створенні електронного документа. На виконання цього розпорядження УЗ підготувала відповідний Наказ МТЗУ від 01.11.2010 № 800. При його підписанні ми узгодили з причетними всі спірні питання:

з Мінекономіки (Держкомпідприємництво) – життєвий цикл електронної накладної та відповідальність сторін за внесення в нього даних,

з ДССЗЗІ (Державна служба спеціального зв’язку та захисту інформації України) – електронний формат документа,

з Держархівом – порядок його автоматизованого зберігання з організацією доступу до електронних накладних. До цього нам довелося робити спеціальний ПАК (програмно-апаратний комплекс) АЕДО (Архів електронного документообігу), у якому зберігаються документи, на які є сертифікат КСЗІ (комплексна система захисту інформації). Усе це дало нам підстави визнати електронну накладну як юридично значущий документ.

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

Підтвердженням цього є той факт, що Україна – єдина країна, при порівнянні з найближчим зарубіжжям, у якій клієнти оформляють 100% перевізних документів у внутрішньому сполученні виключно в електронному вигляді. Цей досвід дав нам можливість першими разом з ВАТ «РЖД» у 2014 році запустити повноцінний електронний перевізний документ на повернення порожніх вагонів між нашими країнами. На сьогодні близько 97% таких вагонів повертаються в Росію з України без оформлення паперового документа.

Тоді як відбувається електронний документообіг між внутрішніми підрозділами УЗ і у відносинах УЗ-клієнт?

Почнемо з відносин УЗ із клієнтом. Процес починається з оформлення договору на організацію перевезень. Поки в паперовому вигляді, але плануємо й в електронному. Перший досвід з одностороннім підписанням у нас відбувся в лютому 2018 року. Тоді понад 7 тисяч клієнтів скористалися цією можливістю, що дозволило скоротити термін підписання договорів з 3-х місяців до 2-х тижнів.

Клієнт після реєстрації договору в Єдиній електронній картотеці клієнтів отримує Код платника. Усе! Можна працювати.

Далі через АС «Месплан» клієнт залишає замовлення на місяць і підтверджує його оперативними заявками вже протягом поточного місяця. Якщо заявки на виконання замовлення підтверджені, зокрема портами, елеваторами, великими вантажовідправниками з урахуванням можливостей станцій і під’їзних шляхів, можна переходити до оформлення пам’яток на подачу / прибирання вагонів і перевізних документів. Це робиться в АС Клієнт УЗ. Самі електронні документи зберігаються, як я вже говорив, у ПАК АЕДО.

Тепер вступає внутрішній документообіг компанії. Оскільки всі наведені автоматизовані системи є частиною Єдиної автоматизованої системи керування вантажними перевезеннями (АСК ВП УЗ-Є), то всі оформлені документи потрапляють до неї. Після цього всі документи і, відповідно, необхідна інформація стають доступними в межах компетенції всім працівникам компанії, що відповідає за перевізний процес. Таким чином, на базі заявки та інформації з пам’ятки формується перевізний документ. На базі перевізних документів формуються натурні листи на поїзд. На базі натурних листів формуються сортувальні листи або передавальні відомості. На базі розкредитованих перевізних документів формуються податкові накладні та переліки для клієнтів. Усе зав’язано в єдиний технологічний процес.

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

Це 100% усіх внутрішніх корпоративних користувачів УЗ?

Усі, хто має бути підключеним, підключені. Усі учасники внутрішнього корпоративного документообігу. Система створювалася в 2002-2004 роках. Зараз вона, з одного боку, повністю охопила внутрішній бізнес-процес, а з іншого – до неї після 17 років є багато запитань щодо розвитку й удосконалення. Можливо, навіть серйозного вдосконалення… над цим ми думаємо. Але загалом накази, розпорядження, контроль виконавської дисципліни, скарги клієнтів і багато іншого, що необхідно для внутрішньокорпоративної організації робіт, реалізовано в електронному вигляді. На 100%.

А з якими проблемами доводиться стикатися розробникам цих систем на місцях?

У нас немає розробників на місцях, у нас є спеціалізована філія – проектно-конструкторське технологічне бюро інформаційних технологій (ПКТБ ІТ), яке відповідає за основні розробки. Є філія ГІОЦ, яка експлуатує автоматизовані системи.

До основних проблем можна віднести такі:

  1. Компанія реформується. Глобально й серйозно. Ми об’єдналися з погляду корпорації в єдиний процес, в єдину компанію. Далі почався другий етап – виділення бізнесів у самостійні структури. Тобто не за територіальним принципом, як раніше було. Тепер 6 територіальних філій не мають тих повноважень, які були. З’являються вертикально інтегровані філії за бізнес-напрямами: пасажирські перевезення, перевезення вантажні, ремонтні компанії тощо. Так ось до 6 залізниць, які організовували весь перевізний процес, тепер додалася велика кількість нових філій, які перебрали на себе частину функцій (наприклад, ЦТЛ, ЄРЦ, ГІОЦ). І зрозуміло, що відносини всередині компанії перебудовуються. Перебудовуються досить динамічно. Нам як власникам ІТ-технологій необхідно швидко підлаштовуватися. Іноді затримка призводить до мільйонних втрат щодня. Відповідальність колосальна.
  2. Друге – як наслідок першого – це погано опрацьована нормативна база. Все будується «з коліс». Залізниця – технологічно дуже складна організація, і коли ми щось змінюємо, ми маємо це все нормативно прописувати. Тому багато робимо в паралельному режимі. Це й зрозуміло. Ми до цього готові.
  3. Кваліфікаційний рівень фахівців. Є фахівці високого рівня, але їх мало. Основна проблема – конкуренція на ринку праці. А наші кадри – це айтішник, який не просто вміє програмувати, а ще й знає залізницю. І це прикро, коли люди знають залізницю, знають технологію, усі наші нормативні документи, мають певним багаж знань (це для нас золоті люди) і йдуть.
  4. Чисто айтішна проблема – досить застарілий парк комп’ютерних систем, апаратного забезпечення, повільні канали зв’язку, на яких ми працюємо.

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

Звичайно ж так! Просто цей процес у нас йде ривками.

Ми зробили перший глобальний крок: основні перевізні документи й пам’ятки ГУ 45, ГУ 46 перевели в електронний вигляд. Дали можливість клієнту працювати і, так би мовити, десь зобов’язали його перейти на електронну форму. Після невеликих дебатів він все-таки пішов. Ті ж заявки на перевезення, ГУ 12 – тут у 100% випадків. Але щодо пам’яток на подачу / прибирання – не було такої «зобов’язалівки». Хто захотів – користується, хто не захотів – ні. І на цьому в нас зупинилося.

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

Як ми говоримо, завтра у нас буде певний ринок, де люди зможуть замовляти локомотиви, бригади. Звідки я знаю, що там будуть планувати?! Хтось планує у своїх, хтось у чужих вагонах. Це швидше система замовлень. Не планування, а саме замовлень.

Сьогодні ось це слово «планування» та слово «місячне» вносять плутанину. Насправді це лише заявки.

У зв’язку з тим, що ми монополісти, нам доводиться брати буквально всі заявки й прохання. Але це зовсім не план, і плану з цього жодного не виходить. Так ось, наступна система, яку ми поки обговорюємо й до якої зараз готуємо свої комп’ютери, буде більше схожа на систему обробки замовлень. Можливо, вона наполягатиме на погодженні суміжників, портів, власників вагонів, елеваторів або локомотивів. Це буде як поле для спільної гри: А, може, пограємо в “Хто й що хоче робити”?» Не треба обмежувати гру місяцем і тим, що це план. Це не план. Це угода про те, чого ми хочемо. Беремося або не беремося робити.

Другий момент.

До планування ми ще хочемо укладати електронні договори.

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

Це глобальний договір. Ми нарахували близько 90 видів договорів, які укладає клієнт з УЗ для різних цілей. Це було б просто зручніше й швидше. Усі дані є. Клієнт підтверджує, що згоден працювати в наступний період, на старих / нових або додаткових умовах. Наприклад: «Хочеш торгуватися за вагони на ProZorro? – Так, хочу! – Ось додаткова угода в електронному вигляді й не треба нікуди їхати!» Підписав і все. Електронний підпис.

Тоді буде переглядатися робота з електронними ключами?

Ні, щодо них не треба нічого переглядати, вони вже існують. Це в законі прописано. Просто буде забезпечена можливість підписувати.

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

У судах таке не приймається?

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

А є технології інтеграції інструментів УЗ, IT-систем в API-системи клієнтів?

Є сервер узгодження, який можна поставити в себе на комп’ютер, і він буде взаємодіяти з нашою системою С-Клієнт і все це організовувати.

Які завдання вже поставили або будуть поставлені розробникам оновленої системи «Месплан», «Рікплан», або як там вона буде називатися? Уже намічено орієнтовний період запуску?

Усі, хто цікавиться залізницею, чомусь у розмовах ходять довкола Месплану. Чому Месплан? Насправді проблема Месплану в тому, що ця система зроблена за старою нормативною документацією, за старою технологією, яка сьогодні не влаштовує ринок. Насправді, сама система «Месплан» виконує одну функцію з 10 – це прийом заявок. І все! Це ось, як стати в чергу.

Тебе поставили в чергу або не поставили. Ти записався на прийом до лікаря або не записався. Потім, якщо записався, рано чи пізно потрапиш. Адже лікування не полягає в тому, що ти взяв папірець до лікаря. Лікування починається потім. Чомусь про це ніхто не говорить. Тому ми розглядаємо весь процес організації перевезення  – від заявки до… до можливого виставлення претензії.

До слова, ми хочемо автоматизувати претензійну роботу. Є бачення та розуміння, як спростити клієнту процедуру подачі претензії, щоб наша комп’ютерна система сама могла аналітично визначити, чи дійсна ця претензія, чи має вона право на існування.

А в цьому напрямку яка робота ведеться? Чи є взаємодія з тими ж органами юстиції?

Ні, це ж внутрішня претензія. Клієнт виставляє претензію перевізнику. Тільки в тому разі, коли перевізник дасть відмову в її задоволенні, клієнт може піти в суд. Не в орган юстиції, а в суд. Це вже друга частина роботи претензії: подати позов. А поки – претензія. В основному, десь у 90-95% випадків, усе вирішується на рівні претензій. Або претензія задовольняється, або задовольняється частково, або не задовольняється. Усе!

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

Тобто передбачаємо:

Перше – подачу претензії в електронному вигляді з первинним контролем достовірності даних.

Друге – допомогу експерту. Система бачить, коли було перевезення. Вона готує об’єктивну довідку для того, хто аналізує претензію, щоб він не рився по базах. Це відразу повна картина, яка потрібна для аналізу й докладається до претензії.

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

Все прозоро. Але цієї системи ще немає, ми її робимо.

А чи є якісь зміни в плануванні транзитних перевезень, які вимагають додаткового узгодження?

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

А побажання клієнтів? Ну зараз же потрібно буде разом з реформуванням змінювати цей…

У нас не буде працювати система заявок і система оформлення документів у окремих ІТ-середовищах, це буде одне й те ж середовище. Але воно буде розвиватися, 21 століття. І коли хтось скаржиться: у мене Windows 95, – ну зрозуміло, що його ніхто підтримувати не буде, тому що там потрібні спеціальні рішення, спеціальні процедури.

Тобто якщо клієнт йде зі старим комп’ютером, то система може йому відмовити. Ми й в УЗ стикаємося з тим, що багато наших систем, які ми розробляємо, при впровадженні не працюють на застарілих робочих місцях. З’ясовуємо, що ці робочі місця куплені у 2002 році й на них просто не можна поставити нічого сучасного. Програма заміни комп’ютерів існує тому, що нові технології не можуть працювати на мотлоху. Це теж треба розуміти. Якщо ж стоїть сучасний нормальний комп’ютер, і система не працює, то, швидше за все, це справа в налаштуваннях. І фахівці ГІОЦ повинні просто підказати.

Чи буде ця система платною?

Вона не повинна бути платною. Дивіться, перше…

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

Я зрозумів запитання, тому так: система робиться УЗ за гроші УЗ для клієнта. І ті базові функції, які ми прописуємо, будуть безоплатні. Ну, наскільки я розумію.

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

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

Що стосується «єдиного вікна». На якому етапі процес його створення, та коли зрештою буде результат?

З портами не може бути такого ось «єдиного вікна». Швидше, його намагаються зробити, але насправді залізниці цього не треба.

Це може хтось робити для себе скільки завгодно. А от що потрібно залізниці й  порту?! Ми ніяк не можемо підписати угоду й вийти на нормальні відносини. Нам потрібно бачити роботу порту й прихід вантажів на нашу адресу, щоб розуміти логістику підходу кораблів і логістику обробки цих вантажів у портах, щоб розуміти, як подавати туди порожні або будь-які інші вагони, який перевізник задіяний у вивезенні з порту, щоб наші вагони там не пропадали нескінченно. Умовно кажучи, на якийсь порт йде залізнична гілка, і хтось спритний поставив туди свої вагони. А вантаж ще бовтається в морі. Вагони стоять, забили шлях. Ми починаємо витягати ті вагони, поставляти ті, які прибули, тобто робити дику роботу через нестикування подачі вагонів.

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

В ідеалі, якою ви бачите взаємодію? Конкретна кількість контрактів на перевезення морем?

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

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

У нас є документ, парафований, але не підписаний АМПУ, про технологічну взаємодії порту та залізниці.

Імовірно таке вирішення питання, коли між Укрзалізницею та АМПУ виникне організація, яка буде збирати на себе всю цю інформацію, адмініструвати її та передавати?

А сенс мені цю контору годувати? Це буде перекладач із залізничної мови портовою? А чи не простіше нам з портом домовитися безпосередньо?!

 

Отримайте тестовий доступ до статистики та аналітики