Победит ли реальный бизнес ИТ-моду? Мнение скептика, часть 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.
Рэй Курцвейл предсказывает технологическую сингулярность к середине века. Наберемся смелости поправить авторитетного визионера: в сфере бизнес-применения сингулярность почти наступила.
Можно открывать глаза.