Принципи автоматизації облікових процесів на прикладі роботи з системами SAP

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

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

• вдосконалення програмних продуктів в цілому (згадаймо еволюцію SAP від R/2 до S/4HANA та хмарних технологій), що зазвичай обумовлено об’єктивним та безперервним процесом трансформації інформаційних систем та технологій;
• побудова алгоритмів бізнес-процесів або їх вдосконалення.

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

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

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

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

Об’єктивні: технічні особливості системи, функціонування стандартного рішення SAP тощо.

Суб’єктивні: що враховують побажання та можливості клієнта.

Володіючи рисами дослідника, психолога та художника, SAP- консультант дотримується наступних принципів при впровадженні рішень.

Перш ніж будувати концепцію бізнес-процесу в SAP, потрібно дослідити відповідний стандартний процес та стандартні можливості системи. Досить багато розробок (так звані Y-програми в термінології SAP), а також «доопрацювань» наявних стандартних програм з’являються лише тому, що консультант вирішив робити усе «з нуля», маючи упередження та/або страх щодо стандартної (часто незнайомої для нього) функціональності.

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

Іншим ірраціональним прикладом є розробка певної функціональності «з нуля», яка насправді може бути реалізована в SAP завдяки стандартним можливостям системи. ?

На нашому досвіді доводилось зустрічати системи, у яких, до прикладу, замість стандартного процесу платежів (у тр. F110), створювались Y-об’єкти, на основі яких генерувався файл вихідних платежів. Такий підхід також спричинював додаткові затрати ресурсів підприємства при завантаженні банківської виписки, адже в такому випадку діє правило: нестандартність певного кроку процесу обумовлює нестандартність наступних його етапів або наступних процесів. Також часто зустрічаються випадки, коли на базі активованих модулів намагаються розробити функціональність, що є стандартною для інших модулів.

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

На будь-якому проєкті впровадження SAP (звісно, якщо це не SAP S/4HANA Cloud Public edition) неможливо обійтись без маленьких розробок. З нашого досвіду ми рекомендуємо під час процесу розробки слідувати правилам, які ґрунтуються на принципах побудови стандартних програм SAP:

• За можливості використовувати стандартні об’єкти, а не придумувати свої. Наприклад, зазвичай немає потреби додавати окреме Y-поле у стандартні таблиці, якщо для збереження необхідних даних можна використати стандартне поле у фінансовому документі. Іншим нераціональним прикладом є бажання придумати свої назви полів у Y-таблиці, якщо такі вже існують у стандарті: наприклад, поле для збереження ID власного банку доцільно визначити як HBKID, а не називати його на кшталт “YID_BANK_HOUS”.
• Створювати Y-таблиці об’єктів та їх описів, що використовуються у налаштуваннях для нашої програми. Звісно, при цьому бажано не суперечити попередньому пункту. Як приклад, недоцільно створювати окрему Y-таблицю із переліком власних банків та їх рахунків, адже такі об’єкти можна отримати зі стандартних таблиць T012 та T012K.
• Створювати Y-таблиці, що дозволяють налаштувати (а отже змінити чи видалити) певні правила, за якими функціонуватиме наша розробка.

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

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

З метою контраргументації, мої колеги-користувачі жартома вибудували свої «антиаксіоми» ?, з якими консультанту, як психологу, доводиться працювати:

1. Роздрукувати, підписати та віднести в архів.
2. Нічого не працює (зазвичай, коли має місце випадок, який виникає дуже рідко);
3. Система мала сама зрозуміти.

Всім гарного настрою та ефективної автоматизації бізнес-процесів із SAP!