У цій статті я не буду розповідати про плюси і сильних сторонах цієї системи з точки зору функціональності - нехай цим займаються маркетологи. Я, як IT-фахівець, хочу поділитися з вами своїми враженнями про реалізацію цього продукту.
Бувають такі інтерфейси, на які дивишся і відразу стає зрозуміло, куди потрібно натиснути, щоб виконати ту чи іншу дію. Так ось ... це не про SAP. Перший раз, коли я побачив стартовий екран SAP, подумав, що це просто дуже-дуже стара версія, яку я якось випадково запустив. Але ж ні, це була цілком сучасна версія. Інтерфейс розробляли десь в 90-х, там він і залишився до цих пір.
Стартовий екран SAP ERP
Вчитуюся в цей страшний, скоєно незрозумілий простому користувачеві, екран і розумію, що передав занадто багато вхідних даних.
Це я зараз знаю, що не можна передавати занадто багато значень в поля селекційного екрану, так як SQL-запит перевищує якийсь там допустимий розмір в кілобайтах і через це програма переривається з виключенням DBIF_RSQL_INVALID_RSQL. Причому, немає ніякої конкретної цифри, все залежить від довжини переданих значень, але експериментальним шляхом отримана цифра рівна приблизно 1500-1800 значень. Але як все це пояснити користувачеві? Як пояснити, що він повинен 4 рази запустити транзакцію, якщо йому хочеться отримати відфільтрований по 5000 значень список. До того ж, в одних транзакціях немає ніяких обмежень, а в інших є.
Ще ситуація. Відкриваю я транзакцію «MIRO - створення вхідного рахунка-фактури», довго заповнюю шапку, вказую системний номер документа входить поставки, на підставі якого автоматично заповнюється позиціями таблична частина рахунку-фактури. З тисячі позицій мені потрібно було 100 видалити. Я знаходжу ці позиції, довго виділяю їх і тисну кнопку «Видалити». Як думаєте, що повинно статися після виділення позицій і натискання кнопки «Видалити»? Ось я теж так само подумав. А розробники SAP думали якось по-іншому - віддалилося 900 невиділених позицій. «Гаразд», - подумав я, - «зараз натисну CTRL + Z і все поверну назад». Ну, ви зрозуміли вже, так? Скасувати цю дію не можна, тому довелося перезапускати транзакцію і заново забивати всі дані.
Це я вже потім прочитав спливаючу підказкою до кнопки «Видалити», де було сказано, що втечуть невиділені позиції. Така поведінка кнопки тільки в цій транзакції. В інших транзакціях кнопка «Видалити» видаляє виділені позиції.
Повідомлення про помилки не несуть взагалі ніякого смислового навантаження. Ось що може означати помилка «Код податку V0 ще існує»? Спочатку я подумав, що це якийсь кривий переклад, але англійський варіант «Tax code V0 also exist» і німецький «Es existiert noch das Steuerkennzeichen V0» теж неінформативні. А означає вона те, що код податку в табличній частині не збігається з кодом податку в шапці. Часто на профільних форумах можна знайти теми «У мене така-то помилка. Що вона означає? », В яких люди грають в угадайку, поки той, хто вже настав на граблі, не дасть відповідь.
Інтерфейс ніяк не стандартизований. Десь меню зліва, десь праворуч. Десь кнопки зверху, десь знизу. Десь взагалі ніяких кнопок немає, а всі дії виконуються через головне меню. Десь іконки на кнопках одні, десь на тих же кнопках інші. Навіть гарячі клавіші в різних транзакції для одних і тих же дій відрізняються. І це стосується не тільки кнопок, але і табличних частин, вкладок і т.д. - єдності немає, всюди все по-різному. Видно, що кожен розробник ліпив інтерфейс, як йому заманеться, і ніякого контролю за цим не велося. Дизайнерів в команді не було. Схоже, це через те, що в момент розробки особливо серйозних конкурентів на ринку не спостерігалося, тому вирішили, що потрібно розвивати функціональність, а інтерфейс користувачі «проковтнуть» будь-хто.
З цим інтерфейсом можна навчитися працювати двома способами: або хтось довго буде вас навчати цьому, розповідаючи тонкощі кожної транзакції і показуючи підводні камені, або самостійно, не перестаючи наступати на нескінченні граблі. Найчастіше навчання проходить за комбінованим сценарієм: консультанти пишуть операційні інструкції з мінімально необхідними для роботи відомостями, а далі користувач сам бродить в цьому дрімучому лісі, постійно забезпечуючи консультантів зарплатою звертаючись до консультантів за допомогою.
Останнім часом в SAP зрозуміли, що сіли попою в калюжу з приходом ефективних менеджерів, розпещених айфона і вибирають софт по зовнішньому вигляду, потрібно щось змінювати в інтерфейсі. Тим більше, конкуренти вже давно підтяглися по функціональності. Тому SAP намагається робити якісь кроки в цьому напрямку і створює замість старих транзакцій нові, які називаються enjoy-транзакції. З'являються якісь нові теми оформлення з кнопками в стилі Android, але поки, як мовиться, «скільки на осла бантиків не вішати ...».
Розповідати про принади інтерфейсу можна нескінченно, але давайте підемо далі ...
Складається враження, що на російську мову інтерфейс переводився в такий спосіб. Спочатку в якомусь Magic Gooddy перевели всі фрази з німецької на англійську, потім там же з англійської на російську. Потім розподілили перекладені фрази між людьми і вони почали їх вручну передруковувати в SAP ERP, іноді вносячи правки. Причому, частина людей або взагалі російська мова не розуміли, або вони були настільки ліниві, що ніяких правок не вносили.
Чому переводили в Magic Gooddy? Тому що не може людина перевести пункт налаштувань «Country-specific requirements» як «Країнні вимоги».
Чому передруковували вручну? Тому що зустрічаються друкарські помилки і граматичні помилки. Наприклад, «Щапрос на перенесення», «Оподаткування» і «уважного» явно друкували руками. Зустрічаються також скорочення слів, щоб не виходити за рамки допустимої довжини тексту.
Чому люди не розуміли російську мову? Тому що навіть при передруці російськомовний чоловік мав засумніватися, побачивши фразу «Пушномолочная свиня-несучка» - так до певного часу називалася програма RAIMEWMS (зараз назва вже виправили). В оригіналі вона називається «Eierlegende Wollmilchsau», що перекладається як «Майстер на всі руки», але розумний Magic Gooddy порахував, що Wollmilchsau - це 3 окремих слова (Woll, milch, sau) і перевів фразу «Eierlegende Woll milch sau» як « яйце укладання вовни молока свиноматки ». Залишається тільки гадати, як це потім перетворилося в «Пушномолочная свиня-несучка».
Так-так, я все ще розповідаю про той самий SAP ERP, ліцензії якого стоять багато тисяч доларів і за впровадження якого організації викладають сотні мільйонів рублів.
Бо більша частина знань консультантів і розробників або передається у спадок від старшого покоління до молодшого, або виходить методом «тику». Якщо пощастить, то можна щось знайти на профільних форумах і в приватних блогах, якщо немає - колупайся сам, відладчик тобі в допомогу.
Якщо консультант знаходить якусь помилку в функціоналі SAP (а вони зустрічаються у величезних кількостях), то відразу ж він намагається знайти підходящу SAP Note (ноту) для її виправлення. Немає конкретного визначення, що таке нота. Нота - це або патч, що виправляє помилку в стандартному функціоналі, або інструкція, яку користувач повинен виконати в системі, або опис налаштувань, або доробка функціональності під змінилося законодавство, або просто пояснення деяких моментів.
Розробка в SAP ERP здійснюється на мові ABAP. Для звернення до бази даних використовуються Open SQL-запити, які дуже схожі на SQL-запити. Синтаксис тут обговорювати не буду - суб'єктивна річ. Він мені не подобається, але звик до нього швидко.
Назви таблиць, полів і змінних, як і назви транзакцій, ніякого сенсу в собі не несуть. Дивлячись на Open SQL-запит SELECT, неможливо навіть близько здогадатися, що за дані він вибирає з бази. Потрібно або заздалегідь знати, що зберігається в оброблюваної таблиці, або по ходу дії в цю таблицю лізти через браузер даних і намагатися зрозуміти, що в ній.
У SAP передбачена можливість доопрацювання стандартної функціональності. Правити стандартний код, попередньо отримавши спеціальний ключ розробника для стандартного об'єкта, можна, але вкрай небажано. Замість цього розробнику пропонується використовувати так звані USER-EXIT. По суті, це порожні функції з наперед заданими вхідними та вихідними параметрами, розкидані по стандартному коду. Викликаються ці функції до або після якоїсь події. Для редагування коду цих функцій спеціального ключа не потрібно. Пізніше до USER-EXIT додалася ще одна можливість розширювати стандартну функціональність - BADI. Це те ж саме, що USER-EXIT, тільки об'єктно-орієнтоване. Навіщо воно з'явилося і чому, якщо вже воно з'явилося, не відмовилися від USER-EXIT - мені незрозуміло, тільки зайвої плутанини додалося.
Оскільки ніякої офіційної документації по USER-EXIT і BADI немає, то, щоб знайти підходяще місце, куди можна дописати свій код, потрібно або сидіти в отладчике в пошуках цих порожніх функцій, або студіювати форуми в надії, що хтось уже стикався з такою необхідністю. Часто буває, що для однієї і тієї ж задачі підходять різні USER-EXIT і BADI. Через це трапляється так, що на одному проекті різні розробники / консультанти вибирають різні USER-EXIT / BADI, і код, який мав би логічно бути в одному місці, розкиданий по декількох місцях.
Складається враження, що цей продукт робили якісь інші німці: не ті, що роблять BMW, Mercedes і AUDI. Процес розробки якийсь абсолютно безконтрольний: в коді безліч помилок, які можуть роками не виправлятися; кожен розробник називає змінні, як йому заманеться; поновлення криві; нові інструменти з'являються недопрацьованими і такими залишаються, поки не стануть старими; ... продовжувати можна довго.