Статья

Победит ли реальный бизнес ИТ-моду? Мнение скептика, часть 2

Интеграция
мобильная версия
, Текст: Алексей Галущенко

В первой части мы пришли к осознанию фундаментальной неработоспособности в современных условиях ERP-парадигмы последнего полувека, и наметили контур требований к ее замене – интеллектуальным управляющим системам предприятия (intelligent enterprise managing, IEM).

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

Первым условием имплементации IEM является исключительная всеохватность, она же единственность. Все без исключения цепочки создания стоимости компании находятся в контуре IEM (в идеале – все структурированные бизнес-процессы вообще), а IEM является единственной управляющей системой предприятия (в идеале – единственной системой вообще).

Реализация принципа единственности и всеохватности приводит к единству информационного поля предприятия с транзакциями в реальном времени, а также к работе всех сотрудников компании в одной «системе».

Функциональность всего зоопарка трехбуквенных «модулей» ERP реализуется средствами IEM.В отдельных случаях, когда дублирование специфических операций вроде низкоуровневого управления контроллерами станков (или рисования дизайн-макетов во внешних графических пакетах) представляется избыточным, соответствующее ПО связывается с IEM-системой и далее взаимодействует с ней по подчиненной модели «плагин-браузер».

IEM и в этом случае остается монопольным хранителем и оператором информации о правилах исполнения бизнес-процессов и текущем состоянии предприятия. ERP – интеграция функциональных блоков снизу вверх. IEM – декомпозиция цепочек создания стоимости сверху вниз.

Рабочая ERP-«система» конструируется соединением разрозненных кусков программного кода, каждый из которых (по идее и уверениям продавцов) реализует в себе наилучшие «бест практисы», собранные со всего мира.

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

Представим себе попытку построить «лучшее предприятие» в мире, соединив «лучший отдел продаж» с «лучшим складом» и «лучшим отделом закупок», каждый из которых – призер профильного всемирного состязания.

При этом лучший склад в мире, например, принадлежит индийскому фармпроизводителю, отдел закупок – дубайскому спекулянту электронными компонентами, а отдел продаж – отечественному производителю «липовых» БАДов. Выпустить «отраслевые решения» с «бест-практисами» для фармацевтов и для электронных спекулянтов по отдельности?

Специфичность бизнес-процессов отдельно взятого предприятия определяется далеко не только отраслевой принадлежностью. Организация склада «аптеки за углом» и многомиллиардного фармдистрибьютора отличаются примерно всем, хотя торгуются одни и те же таблетки.

А если вспомнить разнообразие регуляций по юрисдикциям? Понадобятся квадриллионы специализированных «решений», предусматривающих все мыслимые комбинации параметров. Увы и ах: строгая логика заходом с любой стороны приводит к одному и тому же выводу: классическая ERP-система в общем случае неработоспособна.

«Гибкость»? Что ж, представим некий сверхмощный «модуль», например, WMS, качественно адаптирующийся к бизнес-процессам любого склада. Оно? Нет.

Подключив фантазию, нет смысла ограничивать ее полет одним функциональным блоком: с той же степенью правдоподобия представим себе универсальную систему для компании в целом, и... с обратной стороны придем к Первому принципу IEM.

Противоречивость, если не прямая антагонистичность, требований к IEM, выдвинутых первой частью, приводят ко Второму принципу IEM: дуализму природы IEM-системы.

По аналогии с квантово-волновым дуализмом, он же философский закон единства и борьбы противоположностей, он же «инь и ян».

Монолитно единая и всеохватывающая, с точки зрения эксплуатанта, система изнутри является суперпозицией двух жестко отделенных частей противоположной природы и назначения, которые мы назовем «платформой» и «пространством бизнес-логики» (business logic space – BLS).

Платформа – закрытая, инвариантная для всех инсталляций, универсальная. Является IEM-интерфейсом к СУБД.

BLS – открытая, специфично адаптированная к каждой инсталляции, соответственно полностью уникальная. Служит IEM-интерфейсом к прикладному разработчику (в собранном виде – к пользователям).

Платформа полностью скрывает низкоуровневые автоматические механизмы эффективной обработки данных и создает тем самым прикладному разработчику комфортные условия на уровне BLS.

Материальные бизнес-объекты естественно отображаются высокоуровневыми абстракциями IEM-модели: физическому складу соответствует объект «склад», документу – «документ», etc.

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

Скрытие от прикладного программиста сложных, затратных и высокорискованных механизмов обработки данных в платформе, с одной стороны, обеспечивает предпосылки рекордной в сравнении с ERP производительности, а с другой – не менее рекордной надежности.

Гарантированная изоляция прикладного разработчика от сложных механизмов обработки данных позволяет использовать в BLS произвольный высокоуровневый язык программирования.

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

Планка требований к квалификации прикладного разработчика IEM очевидным образом падает с космического уровня ERP-гуру на общий уровень современной прикладной разработки вместе со сроками обучения и величиной заработной платы.

Вернемся к рекордной производительности. Физическое выделение платформы необходимо, но недостаточно (пример – продукция широко известного отечественного вендора). Удивительно, но факт: прогресс СУБД после появления технологии «клиент-сервер» прошел мимо ERP-систем. Универсальность связки типовой ERP с произвольной СУБД хороша только на пресейле. Использование базового SQL гарантирует самую низкую производительность из всех возможных вариантов: шуруповерт без включения в розетку.

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

Плотность интеграции позволяет рассматривать СУБД как в некотором роде часть платформы. Или, наоборот, IEM-платформу как надстройку над СУБД, организующую дополнительный уровень абстракции.

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

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

Чем лучше стандартизованы и формализованы бизнес-процессы компании (в реальности, а не в декларациях и бюрократической макулатуре), тем большая часть человеческого персонала естественным образом заменяется сценариями (виртуальными роботами) IEM-системы.

Очевидное сокращение затрат сочетается с не очевидным (сразу) ростом доходов – сбыт растет вследствие драматического роста качества сервисов («компьютер не ошибается») и их доступности (24х7).

Таким образом, на некоем высоком, но вполне достижимом практически уровне стандартизации бизнес-процессов, предприятие, автоматизированное IEM-системой, превращается в полностью безлюдное.

Речь идет, безусловно, об операционном уровне, потому что креативные функции никакая алгоритмическая система исполнять не может по формально-математическим основаниям. Более того, никогда и не сможет – вне зависимости от вычислительной мощности или изощренности алгоритмов. Таким образом, тезис первой части о невостребованности ИИ усиливается невозможностью его создания в принципе (на алгоритмической основе).

В практической реальности виртуальные роботы IEM заменяют (не менее) виртуальный труд офисных сотрудников, рабочие производств заменяются промышленными роботами, водители – беспилотными автомобилями, etc.

Рэй Курцвейл предсказывает технологическую сингулярность к середине века. Наберемся смелости поправить авторитетного визионера: в сфере бизнес-применения сингулярность почти наступила.

Можно открывать глаза.