Створення інтерфейсу між модулями SAP

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

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

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

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

Переваги від впровадження SAP-системи:

- знижується обсяг роботи, тому що не треба багато разів вводити одну і ту ж інформацію в комп'ютер;

- істотно посилюється контроль;

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

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

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

У період інтенсивного розвитку компаній витрати зростають планомірно і постійно, а доходи досягають певного рівня і стабілізуються. Будь-яка економічна теорія говорить про те, що компанія в міру зростання втрачає в маржі. Іноді тонка нитка, що відокремлює доходи від витрат, рветься. В результаті компанія має гігантські оберти, всі зовнішні атрибути успіху, а насправді працює в мінус [1].

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

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

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

CRM-системою і системою контролю якості, ERP-системи націлені на максимальне задоволення потреб компаній в засобах управління бізнесом [3].

В якості недоліків слід відзначити складності, що виникають на етапі впровадження SAP систем:

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

- опір департаментів в наданні конфіденційної інформації зменшує ефективність системи;

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

Наведемо основні обмеження використання SAP:

- невеликі компанії не можуть дозволити собі інвестувати достатньо грошей в SAP і адекватно навчити всіх співробітників;

- впровадження є досить дорогим;

- система може страждати від проблеми "слабкої ланки" ефективність всієї системи може бути порушена одним департаментом або партнером;

- проблема сумісності з колишніми системами.

Існує думка, що іноді SAP складно або неможливо адаптувати під документообіг компанії і її специфічні бізнес-процеси. Насправді, будь-якому впровадженню SAP-системи передує етап опису бізнес процесів компанії. По суті SAP-система являє собою віртуальну проекцію компанії [4].

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

Мета дослідження - створення інтерфейсу передачі даних між модулями SAP GOP та SAP EOP та вдосконалення механізму його реалізації для подальшої оптимізації.

Для досягнення цієї мети були поставлені наступні задачі:

1) Впровадження нового модулю в SAP, а саме локальної системи.

2) Виявлення інфотипів, які потребують зміни для підтримки локального розрахунку і розрахунку часу в SAP, не зупиняючи розрахунки заробітної плати при впровадження законодавчих або інших змін в систему.

3) Впровадження змін для більшої незалежні основної системи і локальної системи.

Впровадження відбувається в 4 основних послідовних етапи:

а) Фаза 1: з'єднання встановлюються з доступними тестовими системами. Крім транспортування, яке йде в основну систему, дані також імпортуються в додаткову систему підтримки, щоб ці обидві системи перейшли в синхронізований стан ;

б) Фаза 2: впровадження пробної версії модуля після поновлення пакета оновлення основної системи;

в) Фаза 3: реалізація трирівневого ландшафту (розробка тестування виробництво);

г) Фаза 4: go-live, а саме повноцінне функціонування нового модулю пов'язаного з основним.

Після останньої фази користувачі отримують в своє розпорядження «клоновану» версію основної системи для управління часом роботи і розрахунку заробітної плати.

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

Процес повної зайнятості і нарахування заробітної плати переходить на нову систему. Хоча деяким користувачам, як і раніше, необхідно надати доступ до основної системи для підтримки глобальних інфотипів, для яких обчислення будуть виконуватися в «клонованій» системі [5].

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

Причиною цього є наступне:

а) інфотипи Запланований робочий час і Автомобілі тісно інтегровані з процесами управління часом і розрахунками та тісно пов'язані з розрахунком заробітної плати;

б) у більшості країн, ці 2 інфотипи набагато більш схильні до законодавчих змін і змін конфігурації; наприклад, нещодавно в Україні було впроваджено нового святкового дня. Зміни в графіках роботи, правила керування автомобілями і тому подібні зміни повинні виконуватися як в основній, так і в «клонованій» системі [6].

На рис. 1 представлена розроблена мапа інфотипів між двома системами.

Рис. 1. Система розподілу інфотипів між модулями

Опис кожного інфотипа наведено у табл. 1.

Таблиця 1. Інфотипи з динамічними заходами

інфотип модуль інформаційний

Оскільки інфотипи діляться на глобальні та локальні, динамічні дії можна розділити на 4 групи:

а) глобальний глобальний

б) локальні локальні

в) глобальний локальні

г) локальний глобальний

Кількість динамічних заходів у кожній з цих чотирьох груп показано в табл. 2.

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

В іншій системі (де інфотипи будуть лише відображатись) динамічна дія ніколи не буде запущена.

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

а) Зміни необхідні для основної системи наведені у табл. 3-5.

Оскільки цільові інфотипи більше не підтримуються в основній системі, ці динамічні дії повинні бути дезактивовані в ній.

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

Зміни необхідні для локальної системи зображені у табл. 6-9.

Вихідний інфотип для цієї динамічної дії підтримується в основній системі, а не в локальній системі. Однак інфотип 0032 вже є частиною відповідних дій, тому цю динамічну дію можна ігнорувати в локальній системі (тримати його в таблиці, оскільки це більше не буде виконуватися) [8].

Таблиця 2

Таблиця 3. Зміни необхідні для основної системи в групі глобальний - локальні

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

Таблиця 5. Зміни необхідні для основної системи в групі локальний глобальний

Таблиця 6. Зміни необхідні для локальної системи в групі локальні - локальні

Таблиця 7. Зміни необхідні для локальної системи в групі глобальний - локальні

Зміни в інфотипах 0000 і 0001 зазвичай виконуються за допомогою заходів з персоналом. Оскільки інфотип 0001 включений в усі глобальні заходи з персоналом, інфотип 0012 може бути включений в усі інфогрупи користувачів. Потім користувач може пропустити інфотип, якщо немає необхідності його оновлювати [9].

Інфотип 0101 є специфічним. Цей інфотип можна зберегти вручну в локальної системи.

Оскільки цільовий інфотип не підтримуються в заходах локальної системи, ця динамічна дія має бути там дезактивована. Необхідно зробити поле «Місце народження» обов'язковим полем в інфотипі 0002 в основній системі [10].

Таблиця 8. Зміни необхідні для локальної системи в групі глобальний - локальні для локального інфотипа 0101

Таблиця 9. Зміни необхідні для локальної системи в групі локальний - глобальний

Зміни, які були запропованої раніше були впроваджені у тестову систему і після вдалих результатів перенесені в основну.

Впроваджено абсолютно новий модуль в SAP, а саме локальну систему, яка дає можливість здійснювати розрахунок заробітної плати і впроваджувати оновлення основної системи одночасно.

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

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

Література

1. Мюррей М. Логистика в системе SAP. SAP ERP и SAP. Эксперт РП, 2017. 321 с.

2. Обухов И. А., Гайфуллин Б. Н. Автоматизация систем управления предприятиями стандарта ERP-MRPII. Москва: Интерфейс-пресс, 2001. 494 с.

3. О'Лири Д. ERP-системы: выбор, внедрение, эксплуатация. Современное планирование и управление ресурсами предприятия. Москва: Вершина, 2004. 272 с.

4. Питеркин С. В., Оладов Н. А., Исаев Д. В. Точно вовремя для России. Практика применения ERP-систем. Москва: Альпина, 2002. 243 с.

5. Ashlock J. Sourcing and Procurement in SAP S/4HANA. Quincy: Rheinwerk Publisher, 2017. 503 p.

6. Logistics with SAP S/4HANA / Bhattacharjee D. et. al. Quincy: Rheinwerk Publisher, 2015. 400 p.

7. Schulz O. Using SAP. An Introduction for Beginners and Business Users. Quincy: Rheinwerk Publisher, 2016. 387 p.

8. Bilay J., Blanco R. SAP Process Orchestration. The Comprehensive Guide. Quincy: Rheinwerk Publisher, 2017. 908 p.

9. Chaitanya M. Creating an SAP Workflow with Workflow Builder Guide. Quincy: Rheinwerk Publisher, 2015. 52 p.

10. Wegelin M., Englbrecht M. SAP Interface Programming. Quincy: Rheinwerk Publisher, 2010. 405 p.

Размещено на Allbest.ru