Індивідуалізація і типізація будуть йти рука об руку
Intelligent Enterprise4 вересня 2006 № 15 (147) "Приватна думка"
Євген Кутікі генеральний директор компанії "БОС. Кадрові системи".
Сьогодні існує думка, що в розвитку корпоративних ІС в російських компаніях з'явився ряд тенденцій, які можуть бути об'єднані в один загальний тренд під назвою "індивідуалізація корпоративного програмного забезпечення". Тенденції індивідуалізації і типізації завжди перебувають у діалектичній суперечності. У якісь періоди часу превалює одна з них. Перші роки цього століття пройшли під егідою панування виробників ERP-систем або "схожих" на них комплексних рішень з управління підприємством. Проте останнім часом спостерігається радикальна зміна парадигми: всі ІТ-спільнота, від виробників прикладних систем управління до їх споживачів на підприємствах, дружно сприйняло ідеї інтеграційного побудови комплексних продуктів за методом "краще в своєму класі" (best of breed) на противагу монолітним ERP. Виникає питання, що ж насправді викликало зміну парадигми. Відповідь очевидна: на ринку проявилася тенденція індивідуалізації ІС з боку споживачів.
Тепер, на новому витку спіралі розвитку, ця макротенденцій знову відродилася. Але прагнення до індивідуалізації в жодному випадку вже не є примітивним запереченням типізації ПЗ. Зараз це принципово новий погляд. Ніхто вже не заперечує вигоди використання промислових прикладних систем від зовнішніх виробників. Ні один топ-менеджер не затвердить бюджет внутрішньої розробки системи, якщо на ринку є готовий промисловий продукт цього класу.
Тоді в чому ж нинішня тенденція індивідуалізації? На мій погляд, на верхньому рівні вона проявляється в тому, що споживач не хоче мати єдину глобальну ERP-систему з типовим функціональним набором, який йому пропонується в її рамках. Він хоче індивідуалізувати список використовуваних різних систем, змусивши їх разом працювати там, де це важливо. А на нижньому рівні тенденція знаходить відображення в тому, що споживач бажає використовувати такі системи, які, володіючи потрібною спеціалізованим функціоналом, не обмежать його можливості в кастомізації, але при цьому збережуть ключове властивість тиражних продуктів - сопровождаемость з боку виробника.
Причини індивідуалізації ІС
Думаю, сьогодні компанії потребують індивідуалізованих ІС в тому сенсі, як ми визначили вище. Тиражовані ERP-системи при спробі впровадити їх у найпростішому вигляді (тобто мінімізувати процес функціональної адаптації, пов'язаний з кастомизацией прикладного коду) просто є малоефективним інструментом. Для закордонних ж ERP-рішень глибока кастомізація неминуча в кожному проекті. Пов'язано це з тим, що як і раніше важко говорити про наявність промислово-тиражованих версій цих ERP-систем для локального ринку. Практика ж показує, що чим глибше кастомізація ERP-системи, тим більше вона втрачає своє ключова перевага - внутрішню наскрізну інтегрованість структури зберігання даних і коду їх обробки. І потрібні начебто невластиві в даному випадку, але вже неминучі інтеграційні тести.У результаті співвідношення ціна / якість при впровадженні ERP найчастіше виявляється дуже високим, іноді настільки, що просто заморожує або зовсім зупиняє розвиток проекту на тих чи інших стадіях і змушує підприємство переосмислювати стратегію створення своєї корпоративної ІС на користь вибору сукупності різнорідних продуктів. З цієї миті зазвичай ініціюється прагматичний підхід до інвестування ІТ. Починається серйозний аналіз найкращих спеціалізованих продуктів на ринку з готовим до використання великим функціоналом.
Технології індивідуалізації
На службі у сучасних підприємств стоять промислово-тиражовані прикладні системи. Це по суті своїй настроюються (модифікуються) програмні комплекси, які залежно від свого класу мають різну пропорцію "готового до використання" і "потребує програмуванні". При цьому всі вони належать, природно, до класу відкритих систем, причому відкритість принципово стосується всього прикладного функціонала, навіть того, що за рекомендацією виробника "чіпати" не слід. На одному полюсі знаходяться продукти "майже коробкові", на іншому - "програми-конструктори", які в принципі мають нульові споживчі властивості без програмування під конкретні вимоги.Сьогодні будь-яка тиражується програмна система, якщо вона претендує на роль індустріального продукту, зобов'язана існувати у двох іпостасях - і як готовий продукт, і як прикладна платформа для створення кастомізовану рішення. Саме це підтримує можливість індивідуалізації ІС. Якщо спробувати розкрити основні складові систем як платформи для створення рішення, то вийде наступний список:
інструментальні засоби розробки прикладного коду для СУБД;
власне тиражна прикладна система, що реалізує базовий функціонал і готова до використання без адаптації;
засоби настройки і створення індивідуалізованих за ролями робочих місць системи на основі базового функціоналу;
засоби модифікації обробки даних в рамках базового функціоналу;
засоби створення додаткових звітів;
засоби підтримки довільних користувача запитів до БД в режимі автогенерації SQL-виразів;
засоби створення додаткової функціональності і підключення її до "дозволених" місцях;
засоби модифікації коду (підміна ділянок коду) базових об'єктів;
кошти заміни базових об'єктів на кастомізованих;
інструменти створення кінцевих користувальницьких OLAP-додатків, що не визначені в базовій функціональності;
програмовані зарезервовані інтерфейси інтеграції системи з будь-яким зовнішнім ПЗ.
В ідеалі завжди потрібен компроміс між обсягом "готового до використання" базового функціоналу і набором засобів кастомізації.
Інша справа - організаційна форма розробки. Питання, що вигідніше - віддати кастомізацію конкретного продукту зовнішнім розробникам або вести роботи власними силами, завжди встає гостро. Моя думка тут однозначно. Особливо на початку шляху, коли система тільки закуповується, перший шлях найбільш доцільний за всіма критеріями: за термінами впровадження, щодо дотримання технологічних норм впровадження та кастомізації, що диктуються виробником, і навіть по результуючим витрат. Головне - правильний вибір підрядника для виконання проекту. Це має бути або сам вендор (відповідне сервісне підрозділ виробника), або сертифікований їм партнер - фірма, за якість послуг якої хоча б опосередковано несе відповідальність виробник.
Що нас може очікувати через 5-10 років?
Спробую дати свій прогноз. Природа завжди розвивається по шляху ускладнення системи в цілому при спрощення та підвищення надійності складових її елементів. "Краще в своєму класі", якщо це відноситься до компоненту загальної системи, завжди перемагає, бо найкраще виконує свою функцію і робить це найнадійнішим чином.
Все більш буде змінюватися фон, на якому відбувається суперництво цих тенденцій. Думаю, що в спілкуванні з кінцевим споживачем на передній план вийдуть фірми-інтегратори. Системна інтеграція нарешті знайде початкову суть. Саме системні інтегратори будуть пропонувати свої готові продукти в якості корпоративних інформаційних систем (а-ля тур, який ви купуєте в туристичному агентстві як замкнутий, закінчений продукт). Замовник свої питання буде формулювати вже інакше. Скажімо, так. Типовий набір елементів (промислових систем) у складі продукту інтегратора або індивідуалізований? Що з успадкованих систем залишити в експлуатації та імплантувати в продукт інтегратора? Типові засоби і методи інтеграції в рамках сервісно-орієнтованої архітектури (SOA) або створення якихось специфічних інструментів? Чи використовувати "готову" функціональність того чи іншого модуля на цій платформі, яку пропонує інтегратор, або приймати рішення про його додатковому тюнінг? Індивідуалізація і типізація завжди будуть йти рука об руку.