Сегодня бытует мнение, что в развитии корпоративных ИС в российских компаниях появился ряд тенденций, которые могут быть объединены в один общий тренд под названием "индивидуализация корпоративного ПО". Тенденции индивидуализации и типизации всегда находятся в диалектическом противоречии. В какие-то периоды времени превалирует одна из них. Первые годы текущего столетия прошли под эгидой господства производителей ERP-систем или "похожих" на них комплексных решений по управлению предприятием. Однако в последнее время наблюдается радикальная смена парадигмы: всё ИТ-сообщество, от производителей прикладных систем управления до их потребителей на предприятиях, дружно восприняло идеи интеграционного построения комплексных продуктов по методу "лучшее в своем классе" (best of breed) в противовес монолитным ERP. Возникает вопрос, что же на самом деле вызвало смену парадигмы. Ответ очевиден: на рынке проявилась тенденция индивидуализации ИС со стороны потребителей.

Теперь, на новом витке спирали развития, эта макротенденция вновь возродилась. Но стремление к индивидуализации ни в коем случае уже не является примитивным отрицанием типизации ПО. Сейчас это принципиально новый взгляд. Никто уже не отрицает выгоды использования промышленных прикладных систем от внешних производителей. Ни один топ-менеджер не утвердит бюджет внутренней разработки системы, если на рынке есть готовый промышленный продукт этого класса.

Тогда в чем же нынешняя тенденция индивидуализации? На мой взгляд, на верхнем уровне она проявляется в том, что потребитель не хочет иметь единую глобальную ERP-систему с типовым функциональным набором, который ему предлагается в ее рамках. Он хочет индивидуализировать список используемых разных систем, заставив их слитно работать там, где это важно. А на нижнем уровне тенденция находит отражение в том, что потребитель желает использовать такие системы, которые, обладая нужным специализированным функционалом, не ограничат его возможности в кастомизации, но при этом сохранят ключевое свойство тиражных продуктов - сопровождаемость со стороны производителя.

Причины индивидуализации ИС

Думаю, сегодня компании нуждаются в индивидуализированных ИС в том смысле, как мы определили выше. Тиражируемые ERP-системы при попытке внедрить их в простейшем виде (то есть минимизировать процесс функциональной адаптации, связанный с кастомизацией прикладного кода) просто являются малоэффективным инструментом. Для зарубежных же ERP-решений глубокая кастомизация неизбежна в каждом проекте. Связано это с тем, что по-прежнему трудно говорить о наличии промышленно-тиражируемых версий этих ERP-систем для локального рынка. Практика же показывает, что чем глубже кастомизация ERP-системы, тем больше она теряет свое ключевое преимущество - внутреннюю сквозную интегрированность структуры хранения данных и кода их обработки. И требуются вроде бы несвойственные в данном случае, но уже неизбежные интеграционные тесты.

В итоге соотношение цена/качество при внедрении ERP чаще всего оказывается очень высоким, иногда настолько, что просто замораживает или вовсе останавливает развитие проекта на тех или иных стадиях и заставляет предприятие переосмысливать стратегию создания своей корпоративной ИС в пользу выбора совокупности разнородных продуктов. С этого момента обычно инициируется прагматичный подход к инвестированию ИТ. Начинается серьезный анализ лучших специализированных продуктов на рынке с готовым к использованию обширным функционалом.

Технологии индивидуализации

На службе у современных предприятий стоят промышленно-тиражируемые прикладные системы. Это по сути своей настраиваемые (модифицируемые) программные комплексы, которые в зависимости от своего класса имеют различную пропорцию "готового к использованию" и "нуждающегося в программировании". При этом все они относятся, естественно, к классу открытых систем, причем открытость принципиально касается всего прикладного функционала, даже того, что по рекомендации производителя "трогать" не следует. На одном полюсе находятся продукты "почти коробочные", на другом - "программы-конструкторы", которые в принципе имеют нулевые потребительские свойства без программирования под конкретные требования.

Сегодня любая тиражируемая программная система, если она претендует на роль индустриального продукта, обязана существовать в двух ипостасях - и как готовый продукт, и как прикладная платформа для создания кастомизированного решения. Именно это поддерживает возможность индивидуализации ИС. Если попытаться раскрыть основные составляющие систем как платформы для создания решения, то получится следующий список:

инструментальные средства разработки прикладного кода для СУБД;

собственно тиражная прикладная система, реализующая базовый функционал и готовая к использованию без адаптации;

средства настройки и создания индивидуализированных по ролям рабочих мест системы на основе базового функционала;

средства модификации обработки данных в рамках базового функционала;

средства создания дополнительных отчетов;

средства поддержки произвольных пользовательских запросов к БД в режиме автогенерации SQL-выражений;

средства создания дополнительной функциональности и подключения ее в "разрешенных" местах;

средства модификации кода (подмена участков кода) базовых объектов;

средства замены базовых объектов на кастомизированные;

инструменты создания конечных пользовательских OLAP-приложений, не определенных в базовой функциональности;

программируемые зарезервированные интерфейсы интеграции системы с любым внешним ПО.

В идеале всегда нужен компромисс между объемом "готового к использованию" базового функционала и набором средств кастомизации.

Другое дело - организационная форма разработки. Вопрос, что выгоднее - отдать кастомизацию конкретного продукта внешним разработчикам или вести работы собственными силами, всегда встает остро. Мое мнение здесь однозначно. Особенно в начале пути, когда система только закупается, первый путь наиболее целесообразен по всем критериям: по срокам внедрения, по соблюдению технологических норм внедрения и кастомизации, диктуемых производителем, и даже по результирующим затратам. Главное - правильный выбор подрядчика для исполнения проекта. Это должен быть либо сам вендор (соответствующее сервисное подразделение производителя), либо сертифицированный им партнер - фирма, за качество услуг которой хотя бы косвенно несет ответственность производитель.

Что нас может ожидать через 5-10 лет?

Попытаюсь дать свой прогноз. Природа всегда развивается по пути усложнения системы в целом при упрощении и повышении надежности составляющих её элементов. "Лучшее в своем классе", если это относится к компоненту общей системы, всегда побеждает, так как лучше всего выполняет свою функцию и делает это самым надежным образом.

Все более будет изменяться фон, на котором происходит соперничество этих тенденций. Думаю, что в общении с конечным потребителем на передний план выйдут фирмы-интеграторы. Системная интеграция наконец обретет изначальную суть. Именно системные интеграторы будут предлагать свои готовые продукты в качестве корпоративных информационных систем (а-ля тур, который вы приобретаете в туристическом агентстве как замкнутый, законченный продукт). Заказчик свои вопросы будет формулировать уже иначе. Скажем, так. Типовой набор элементов (промышленных систем) в составе продукта интегратора или индивидуализированный? Что из унаследованных систем оставить в эксплуатации и имплантировать в продукт интегратора? Типовые средства и методы интеграции в рамках сервисно-ориентированной архитектуры (SOA) или создание неких специфических инструментов? Использовать ли "готовую" функциональность того или иного модуля на данной платформе, которую предлагает интегратор, или принимать решение о его дополнительном тюнинге? Индивидуализация и типизация всегда будут идти рука об руку.