На вопросы главного редактора IT News Геннадия Белаша отвечает Александр Казеннов, руководитель корпоративной практики ДКИС ALP Group.
Какую полезную информацию могут извлечь эти подсистемы, если раньше они не общались напрямую (например, BPM передает информацию RPA, а последняя не знает, что с ней делать)?
Однозначно ответить на этот вопрос невозможно, все зависит от конкретной реализации и модулей. Если BPM передаст информацию в RPA, RPA навряд ли самостоятельно с ней что-то сделает: все-таки роботу нужно настраивать вручную. Хотя идея, чтобы робот принял описание нового процесса на себя, соединил сведения с модулем данных и самостоятельно собрался в скрипт отработки процесса, привлекательна. Но вот модуль управления НСИ вполне может раздавать информацию во все связанные подсистемы, работающие с конкретными справочниками как в виде конкретных значений, так и в виде ID-ссылок на значения (чтобы не дублировать информацию).
В вашей статье отмечено, что современная ERP (iERP) должна одновременно отвечать трем группам условий. Дальше идет список условий. Насколько реально создать такую ERP-систему, отвечающую всем этим условиям одновременно? Существуют ли сейчас такие ERP-системы?
С одной стороны, технологии готовы к такой интеграции. Но, как правило, они реализованы разными вендорами и собрать их под капотом от имени одного из них – политический и юридический вопрос. С другой стороны, пока программные вендоры договариваются или пытаются создать собственные такие решения (о готовности пока не слышал), интеграторы самостоятельно собирают такие ERP на проектах своих заказчиков из решений-кирпичиков различных поставщиков таких систем.
Ваша компания готова построить в сжатые сроки полноценную ERP-систему, отвечающую вышеприведенным правилам у конкретного заказчика?
Конечно, готовы. Вот только понятие сжатости сроков слишком размытое, так как готовность интегратора не означает готовности заказчика. И поэтому на деле корректнее говорить об адекватных сроках.
Если ваша компания возьмется за такое построение, то с чего вы начнете? Сколько примерно времени понадобится для построения первой версии полноценной ERP?
В этом вопросе все достаточно стандартно. Необходимо понять конкретные бизнес-задачи заказчика с попыткой предсказать и удовлетворить будущие потребности и уже от них, с оглядкой на текущий IT-ландшафт, проектировать новую систему. Начиная примерно с 2016 года в моей практике редко у какого корпоративного заказчика требуется снести всё старое программное обеспечение и устанавливать новое с чистого листа (если только не были допущены уж совсем фатальные ошибки автоматизации). При этом обязательно необходимо сразу же определять имеющуюся и целевую модель данных, включая определение потоков данных и уровня доверия к источникам. Без этого не выстроить архитектурно верный MDM-ориентированный ландшафт с возможностью масштабирования и роста.
В каком порядке вы будете внедрять технологии BPM, Process Mining, Data Lake, ECM, Agile и DevOps, Data-Driven Management? На какие технологии будете обращать большее внимание?
Всё очень сильно зависит от стартовых условий. Где-то можно и нужно делать несколько модулей параллельно, где-то уже есть хороший блок аналитики, но отвратный блок учета (что странно), а где-то наоборот. Но, как правило, необходимо искать золотую середину, то есть автоматизировать блок управленческой аналитики и первичных данных, так как они взаимозависимы. Ну а без DevOps в принципе не построить нормальную по скорости и качеству систему управления изменениями, поэтому он также подключается сразу. Такие вещи, как ECM и BPM из перечисленных, могут подождать.
Могу предположить, что сейчас большинство современных компаний будет готово к внедрению отдельных аспектов целостного подхода ERP. Какие из вышеназванных технологий дадут бóльший экономический эффект?
Вопрос, на который нельзя ответить однозначно. Где-то внедрение качественного блока оперативного учета колоссально снизит издержки на этапах логистики, ручной труд на производстве и т. п. Например, управление обслуживанием заказов в marketplace. А где-то реализация аналитических сценарных моделей «Что, если?» позволит найти новые ниши на рынках, что даст рывок бизнесу (например, у производителя микрочипов). В этом вопросе важно отталкиваться от честного анализа текущего состояния и зон роста.
Чем занимается coзданная в 2020 году лаборатория ДКИС ALP? Как она работает над отдельными аспектами и компонентами ERP?
Ищет зоны повышения производительности в передаче и обработке данных, новые способы сэкономить занимаемое место на носителях данных. Количество информации растет бешеными темпами, соответствующим образом повышать серверные мощности в эпоху дефицита компонентов не только проблематично, но и весьма затратно. Также исследуются новые рыночные решения, их рациональность для покрытия тех или иных задач.
Чуть более месяца назад ДКИС ALP усовершенствовал свою авторскую разработку Process Mining и значительно расширил ее функционал. Что нового появилось в этой разработке и как это ложится в концепцию быстрого развертывания ERP?
В первую очередь очень пригодится анализ качества выполнения сопоставимых процессов внутри компании и между компаниями. Почему, например, процесс товародвижения на одном складе выполняется с нормативами X, а на другом, аналогичном, – с нормативами Y. И всё это в автоматическом режиме. Да и в целом контроль отклонений от эталонов всегда полезен компаниям. Особенно когда для этого потребовалось лишь один раз настроить критерии контроля, далее всё осуществляется автоматически.
Какую роль играют в создании качественных и гибких ERP-систем для заказчика ваши внутренние технологи работы – система управления изменениями, модель бережливого производства и пр.?
Контроль сроков, контроль результатов, качественная обратная связь и минимизация простоев. Всё это – в единых интерфейсах взаимодействия заказчика и исполнителя в рамках работы как над конкретной задачей, так и над проектом в целом.
Каким образом Low Code способен повысить скорость развертывания ERP-систем? Какие новые задачи ложатся в этой связи на разработчика ERP как при проектировании, так и при дальнейшей поддержке таких систем?
Если у заказчика достаточно компетенций для самостоятельного управления рядом функций ERP либо заказчик готов их приобрести, интегратор может сэкономить свои ресурсы на передаче части функций в IT-службу заказчика. Например, создание отчетов, печатных форм, интерфейсные настройки, формулы для расчета данных, различные настройки загрузки/выгрузки данных без низкоуровневого программирования. При этом разработчик таких решений должен четко обозначить границы дозволенного для самостоятельной реализации заказчиком и установить защиту от случайных некорректных воздействий. Это необходимо, чтобы обеспечить высокий уровень производительности системы с сохранением должного уровня качества данных и пользовательского опыта и свести к нулю количество точек отказа системы. Такие решения могут на начальном этапе даже увеличить сроки внедрения системы, особенно если low-code-решения отдельно встраиваются интегратором, но на этапе развития и поддержки сильно сокращают издержки на реализацию «простых» требований к доработкам. Если же модули low code уже заложены вендором во внедряемую систему, тогда, как правило, внедрение проходит заметно быстрее, чем обычно, для интегратора. Но такая экономия может не дать положительного эффекта для проекта в целом, если применение технологии на стороне заказчика будет выполнено с ошибками.
Влияет ли технология Low Code на принятые в ALP подходы к Agile и DevOps?
В сутевой части – нет, так как для нас, как интегратора, это лишь один из способов реализации задачи. Но в свое время пришлось докрутить механизмы выдачи изменений и контроля качества кода для проверки и low-code-решений.