За несколько последних лет технологии корпоративной автоматизации сильно продвинулись вперед, так что многие технические и методические вопросы применения ERP-систем, казалось бы, уже полностью и всесторонне изученные, сейчас явно нуждаются в переосмыслении.
Участники круглого стола
Борис Аксёнов, РЖД, заместитель начальника Департамента бухгалтерского учета
Александр Дудников, Московская пивоваренная компания, ИТ-директор
Михаил Заборов, группа компаний Custis, заместитель генерального директора по стратегическим проектам
Юрий Ипатов, «Трансмашхолдинг», руководитель департамента ИТ
Муза Монамс, «Бауэр Медиа», исполнительный директор
Алексей Нестеров, «1С», директор по ERP-решениям
Intelligent Enterprise: Новые инфраструктурные решения: облака, виртуальные и мобильные рабочие места, вычисления в оперативной памяти (in-memory computing), RFID и другие методы первичной идентификации — вот далеко не исчерпывающий список популярных сегодня концепций, которые могут оказывать влияние на то, что мы понимаем сегодня под системами ERP или, шире, комплексной автоматизации. Действительно ли ERP-системы меняются в новых условиях, и если да, то каким именно образом?
Михаил Заборов: Чисто инфраструктурные технологии — например, RFID или работа с мобильными устройствами, — не меняя систему принципиально, сильно упрощают многие операции в ней, такие как документооборот, приемка, инвентаризация. Скажем, концепция учета остается без изменений, но большой кусок прежнего функционала системы становится гораздо проще, а в пределе вырождается. Например, раньше обычный процесс инвентаризации предполагал определение участков пересчета, формирование задания на пересчет, обработку его результатов, проверку корректности, а при обнаружении ошибок — повторение процедуры. В случае использования RFID достаточно просто «спросить у полки» — и получить абсолютно точные данные относительно количества товаров на ней.
Юрий Ипатов: Для системы совершенно не важно, кто вносит в нее данные — человек или машина. Важны по большому счету две вещи: во-первых, чтобы данные вообще поступали в систему, а во-вторых — чтобы это происходило наиболее эффективно. И здесь мы можем обсуждать определенные инструменты, дающие возможность сократить затраты. Если говорить о RFID-метках, то их использование относится к цеховому уровню и тесно связано с концепцией бережливого производства. На уровне завода есть механизмы, реализация которых тесно связана с развитием ERP.
Александр Дудников: С другой стороны, давайте сравним, как происходила инвентаризация еще пять или десять лет назад и как она происходит сейчас. Раньше всё записывалось на листочках, потом перебивалось в Excel, и лишь после этого итоги инвентаризации — пять цифр — вбивались в ERP-систему. Сейчас мы сканируем штрихкод каждого объекта или считываем его RFID-метку и в систему заносим непосредственно эти данные. Иначе говоря, объемы данных, которые должна обрабатывать ERP-система, у нас увеличились в десятки и сотни раз. Так что никакого упрощения нет и в помине. Точнее, упрощение происходит только для конечного пользователя, а для самой системы — наоборот, усложнение. Инвентаризация требует в десятки раз больше ресурсов (причем выделенных), чем необходимо в обычном режиме работы. Поэтому мы — вполне логично — говорим, что всё это нужно перевести в облако, которое, как известно, выделяет ресурсы по мере необходимости.
То есть технологии каким-то образом цепляются друг за друга, хотя и не относятся к обсуждаемой нами концепции…
Юрий Ипатов: Вообще цель применения любой технологии — это сокращение затрат…
Муза Монамс: …или увеличение прибылей.
Юрий Ипатов: Я знаю, что всегда ставятся две задачи, но будем откровенны — в сегодняшних условиях конкурентоспособность достигается именно за счет снижения затрат.
Борис Аксёнов: По большому счету мы движемся по кругу — или, если угодно, по диалектической спирали. У предприятия есть стратегическая цель, исходя из нее мы ставим определенные управленческие задачи и на их основе строим некоторую систему. В первую очередь проводим реинжиниринг процессов, потом — реинжиниринг всей системы, выстраиваем процесс и смотрим, какие еще инструменты здесь имеет смысл применить. Выбираем инструменты, применяем их и получаем массив данных. Надо сказать, что этот массив с каждым разом становится все больше, а саму информацию мы извлекаем все быстрее. Новые данные позволяют нам дальше развивать наши управленческие решения, мы проводим новый реинжиниринг — круг замкнулся.
Алексей Нестеров: Такой замкнутый цикл реинжиниринга можно реализовать с одной системой только при условии, что она поддерживает соответствующие инфраструктурные и бизнес-технологии.
Муза Монамс: Это можно переформулировать в терминах ИТ-ресурсов. Мы берем ресурс, используем его, получаем больший итог или новое качество, и у нас возрастает потребность в ресурсах, потому что у нас становится больше данных. Так, итерационными кругами, мы движемся к цели, и это абсолютно правильно.
Алексей Нестеров: Да, получается, что перечисленные в вопросе технологии — это инструменты достижения цели. Они действительно серьёзно влияют сейчас на развитие программных продуктов и на приемы информационной поддержки бизнес-процессов. У нас большинство из них поддерживается на уровне платформы, чтобы их можно было использовать и с CRM, и с ERP, и со всеми другими решениями. Поэтому мы можем сказать, что если бизнесу нужно использовать мобильные устройства или RFID-метки на складах либо для проведения инвентаризации, то технологии это позволяют.
Впрочем, надо понимать и то, что существуют технологии, которые, безусловно, являются передовыми, но при этом явно рассчитаны на предложение функционала, избыточного по отношению к реально востребованному. Например, я еще не сталкивался с запросами клиентов на вычисления in-memory. Конечно, потребность в ускорении обработки данных возникает у многих, но ее проще и дешевле удовлетворить с помощью технологии твердотельных жестких дисков SSD — они также в разы повышают производительность системы.
Юрий Ипатов: Да, мы успешно используем SSD.
Александр Дудников: Некоторые технологии сейчас опережают потребности бизнеса, но они не способны преодолевать принципиальные ограничения современных ERP-систем. У каждой из них есть свои ограничения и недостатки, и не существует такой системы, которая поддерживала бы всё, что необходимо для автоматизации бизнеса. Все равно приходится нахлобучивать на нее какую-нибудь CRM, WMS, BI, и так далее, и тому подобное. Так что система комплексной автоматизации бизнеса практически всегда состоит из множества продуктов.
Михаил Заборов: Обычно ERP рассматривают как принципиально единую систему, в которой находятся все транзакции. Требование консистентного состояния ресурсов предприятия в единой системе прописано в концепции ERP. Но происходит и встречный процесс, который можно назвать дезинтеграцией, когда ERP-система разделяется на крупные независимо развиваемые куски. Дезинтеграция диктуется соображениями эффективности: чтобы держать огромную систему на одном сервере, необходимы новые масштабные технологические решения, но при этом может быть так, что несколько обычных серверов позволят получить ту же скорость обработки со значительно меньшими затратами. Кроме того, каждый компонент можно развивать независимо от остальных, а значит, достаточно быстро. То есть вы строите ERP-систему, объединяющую знания об остатках и данные посметного учета, а для всего остального используете некоторые «лепестки» — лучшие в своем классе решения, отражающие специфику того, что вы делаете. И мы наблюдаем, что рост объемов данных и сложности процессов заставляет многих клиентов уходить от попыток решить все проблемы предприятия с помощью одной ERP-системы и принимать стратегию внедрения комплекса взаимосвязанных систем.
Борис Аксёнов: Вообще говоря, это некоторая подмена понятия — мы начали говорить о ERP в более широком смысле слова, правильнее было бы сказать «система комплексной автоматизации». Но системные ограничения здесь действительно возникают — с этим я полностью согласен. У нас в РЖД, в условиях интенсивных потоков данных, если в ERP — точнее, в интегрированную систему — начать вносить все больше и больше детализации, ею через некоторое время станет невозможно пользоваться, потому что на любой отчет будет уходить до двух часов обработки. И здесь уже смотришь на ограничения, пытаясь доступными способами разбивать систему на части — как косвенными методами, затрагивающими механизмы использования решения и логику его работы, так и прямым выделением из него каких-то подсистем.
Юрий Ипатов: Мы применяем следующий подход. Система традиционными методами разбивается на несколько уровней, на каждом из которых определены правила представления и консолидации информации. Различаются три вида информации — централизованная, используемая в консолидации и локальная, которая не передается за пределы завода. За счет такого разделения нагрузка на технические средства снижается.
Борис Аксёнов: Все равно здесь очень многое зависит от реинжиниринга процессов. Когда компания маленькая — скажем, весь ее штат состоит из десяти человек, — они могут собраться, всё между собой быстренько проговорить и выстроить оптимальную схему. И даже если при этом они столкнутся с определенными техническими ограничениями, эти ограничения можно будет оперативно проанализировать и снять тем или иным способом. Когда же, как у нас, большая система и много участников, им сложно договориться, и из-за этого получается много неоптимальных процессов.
У нас в компании такая проблема возникает довольно часто. Допустим, собирается группа, обговаривает проект. На бумагу ничего не положено, но это, казалось бы, не так уж и важно — некий процесс выстроен, и все согласны, что он должен выглядеть именно так. Не тут-то было! Несколько раз я брал листочек и подробно за всеми записывал — ключевые моменты должны уместиться на странице А4, не больше. Дальше я брал заполненный листок и начинал в том же ключе обсуждать пользовательскую модель: то-то передаётся здесь, тому-то необходима определенная информация. И неизменно обнаруживались маленькие тонкости: «— Почему седьмого числа? Я седьмого только отчет закрываю, а документы от поставщика у меня к этому дню вообще никогда не бывают готовы. — Так ты же мне сказал, что дашь. — Сказал. Но я не имел в виду, что седьмого». Казалось бы, мелкое недопонимание на промежуточном этапе обсуждения, но может иметь просто драматические последствия. И таких примеров много.
Юрий Ипатов: «Трансмашхолдинг», конечно, не такой гигант, как РЖД, но и не самая маленькая компания — пять с лишним десятков предприятий, включая огромные заводы. Чтобы у нас не случалось таких обсуждений, мы решили навести порядок с точки зрения методологии и создали единую корпоративную учетную политику, а также единую конфигурацию на платформе «1С», в которой работают и все заводы, и централизованные офисы. Сейчас мы завершаем подготовку отчетности по МСФО.
Итак, ERP распадается, превращается в группу систем. Причины этого коренятся, с одной стороны, в технологической сфере, с другой — в самом бизнесе. И раньше, в общем-то, требовалось снимать подобные ограничения. Консолидация тоже всегда была проблемой…
Алексей Нестеров: У нас накоплен богатый опыт решения проблем с консолидацией. Есть способы, есть методология решения этих задач, и консолидация — далеко не самое сложное из того, с чем нам приходится встречаться.
По нашей статистике большинство холдинговых структур сейчас сталкивается с задачами централизации нормативно-справочной информации, конструкторской документации производственных предприятий, организации централизованного сбыта и снабжения. Это, в свою очередь, влечет централизацию в ЦОДах, заказчиков интересует удаленный доступ для предприятий — через Web-клиент, через тонкий клиент — для того, чтобы быстро принимать решения по тем задачам, которые требуют оперативности. Всё это — реальность бизнеса. Но есть какие-то задачи, какие-то данные, которые остаются на предприятиях локально, и их не нужно консолидировать. Поэтому данные разделяются на те, которые географически распределены и нуждаются в консолидации, и те, что не обязательно консолидировать. Кроме того, данные разделяются по назначению и оперативности: если они нужны высшему руководству раз в месяц для анализа, их нужно обрабатывать совсем не так, как те, что нужны той или иной службе для принятия оперативных решений.
Таким образом, наряду с консолидацией происходит и разделение данных, но тенденция к консолидации все-таки преобладает.
Это наталкивает на мысль об управлении данными. Раньше оно как-то не попадало в поле внимания тех, кто занимался традиционными проблемами внедрения ERP, а сейчас явно приобретает отдельный, так сказать, методологический оттенок…
Муза Монамс: В управлении всегда образуются «качели», которые раскачиваются между двумя полюсами — развитием оперативной текущей деятельности и консолидацией данных для построения общей корпоративной отчетности. Для консолидации все данные хорошо сделать общими, но на уровне отдельного предприятия это замедляет работу с системой, и иногда значительно. Здесь всегда надо иметь очень четкий баланс.
Михаил Заборов: Не стоит увлекаться чрезмерной централизацией данных. Бизнес имеет тенденцию развиваться по новым направлениям: например, торговая компания развивает у себя сервис, потом производство, и эти разные подразделения, которые существуют как бы в одной компании, на самом деле почти не связаны друг с другом. Конечно, у них есть общий корпоративный баланс и очень многое даже описывается одинаковыми терминами, но при этом содержательные различия могут быть более чем заметными.
Александр Дудников: Развитие дополнительных направлений бизнеса происходит всегда, и если одно подразделение холдинга что-то начало, вполне может произойти так, что в дальнейшем этим станет заниматься и холдинг в целом. Новый вид деятельности может быть продублирован и на остальные ячейки холдинга, в том числе и в головную компанию, может даже стать приоритетным направлением для холдинга. Бывают и такие ситуации.
Юрий Ипатов: У нас есть такое понятие, как центры компетенции. Скажем, в Твери находится центр по внедрению ITSM, который работает на весь холдинг, на «Метровагонмаше» — центр по системам оперативно-календарного планирования и учета производства, на Демиховском машиностроительном заводе — по PDM-системам. В каждом таком центре сконцентрированы определенные ресурсы, это всё узаконено.
Вообще это признак достаточного уровня зрелости компании. Сначала ERP, потом эксплуатация, потом какой-то опыт, и только затем — центр компетенции…
Александр Дудников: Да, но это может быть довольно быстрый путь.
Муза Монамс: Если центры компетенции формально узаконены, то да, но фактически они всегда есть. Я думаю, центр компетенции здесь — один из ключевых моментов, то, что обязательно должно появиться при развитии сложных систем.
Юрий Ипатов: Центры компетенции нам нужны, чтобы планомерно двигаться к эффективной организации производства внутри холдинга. Советская промышленность ориентировалась на массовое производство, и все предприятия были выстроены в соответствии с этой парадигмой. Сейчас идет разговор о том, чтобы уйти от массового производства к мелкосерийному, работать по заказам и проектам. Соответственно меняются требования к производству. Мы должны создать мобильные производства, способные производить большой ассортимент продукции.
Борис Аксёнов: Здесь мы немножко лукавим — с учетом того, что заказов становится больше, мы все равно ищем ту конфигурацию заказов, которая будет своего рода имитацией массового производства.
Юрий Ипатов: Нет, тут нет никакого лукавства хотя бы потому, что позаказное производство требует новых методов его организации и соответственно информационной поддержки. Мы убрали кучу станков и создали один центр, сократив за счет этого подготовительно-заготовительные операции и снизив затраты. Мы повышаем эффективность, формируя календарные планы с учетом всех заказов. У нас выработана целая система управления требованиями заказчиков, есть и BI, и data mining, но сотрудники пользуются ими, не замечая этого. Скажем, если нам нужно обсудить с заказчиком повышение цен, мы запрашиваем ценовой департамент и предъявляем убедительные доказательства того, что, например, повысилась цена на металл. Это один из путей применения аналитической системы — информация в ней обновляется ежедневно в 9 часов утра, когда срабатывает общая шина со всеми заводами. Система успешно действует с 2008 года.
Хочу обратить внимание: мы все время сворачиваем на тему ERP в холдингах. На заре концепции ERP мы знали, что ERP-системы различаются в зависимости от типа производства — дискретного, непрерывного, смешанного. А предложений систем для холдингов, для многопрофильных производств немного.
Борис Аксёнов: На самом деле разработчики — что «1С», что SAP — именно так и представляют свои продукты. Вот «1С: Производство», вот «1С: Склад» и т.д. — это и есть холдинг.
Муза Монамс: Мы уже говорили, что начинается специализация ERP-систем. Система перестает быть одним большим ящиком, в котором есть всё, и распадается на отдельные специализированные системы.
И еще одна тема, которую мы чуть-чуть затронули, — переход от массового производства к позаказному.
Алексей Нестеров: Эта тенденция диктует расширение функционала ERP-системы в сторону PDM и PLM. При таком расширении предприятие может быстро просчитать заказ и запланировать его выполнение с учетом того, какие материалы есть, а каких нет. Менеджер по работе с клиентами может оценить сроки исполнения заказов. И получается агрегирование функционала различных систем в одну. В результате функционал ERP расширяется в части PDM, управления ремонтами и т.д. Сейчас мы видим эту тенденцию на крупных предприятиях. А классический функционал ERP при этом шире используется в среднем и малом бизнесе, которому раньше хватало просто учета.
В последние годы в корпоративной автоматизации становятся практически стандартными функции, которые раньше если и использовались, то эпизодически. Среди них — прогнозная аналитика, автоматизация отношений с поставщиками (SRM), системы цехового управления — PDM, PLM. Какой отклик в пространстве ERP-систем это может иметь? В частности, должно ли быть обеспечено прямое включение этих функций в состав ERP или речь идет об интеграции?
Муза Монамс: На самом деле развитие ERP-систем идет несколькими путями — есть и расширение традиционных функций, и прямое их включение, и интеграция с внешними системами.
Юрий Ипатов: Верно. Но в зависимости от холдинга пути можно интерпретировать по-разному. Например, мы строим систему управления обязательствами или управления оборотным капиталом. Это имеет смысл для финансового холдинга.
Наш холдинг — многоуровневый, и нам приходится заниматься очень многими видами деятельности. Но если говорить об SRM-системах, то они больше нужны специализированным компаниям внутри холдинга, которые занимаются, допустим, поставками — примерно половина поставок у нас централизована.
Алексей Нестеров: Действительно, можно сочетать различные пути развития ERP-систем — мы, во всяком случае, так и делаем. Напрямую функция включается в ERP, если она нужна, грубо говоря, восьмидесяти процентам клиентов — то есть подавляющему большинству. Повышается у них спрос на какую-то функцию, которой в ERP-системе раньше не было, — неважно, входит она в классику ERP или нет, — эту функцию, раз на нее есть спрос, надо добавлять. И другой вариант: со стороны двадцати процентов клиентов есть спрос на какой-то расширенный функционал — PDM, ТОиР, СRM, MES-системы цехового планирования. Тогда мы делаем отдельный блок, но на базе нормативно-справочной информации ERP-системы.
Такой блок легко встраивается в ERP, его можно как интегрировать в общую систему, так и поставить отдельно. Например, кто-то предпочитает установить MES в цеху как автономное решение, не связанное с обновлением ERP: цех работает круглосуточно, в трехсменном режиме, а обновления, которые никак не затрагивают MES (они отражают только изменения законодательства), все же требуют какого-то времени. Кому-то удобно объединить системы и синхронизировать данные. Очень важно поддерживать единую нормативно-справочную систему ERP-решения как шину данных для интеграции специализированных модулей.
Каковы ключевые понятия этой интеграции? Первое, как можно догадаться, — это единая НСИ. Плюс к единой НСИ может быть какая-то логика…
Юрий Ипатов: …и учетная политика, конечно…
Алексей Нестеров: …и ключевые бизнес-процессы. Например, материально-техническое обеспечение. В принципе это может быть отдельно развернутая система, где будет управление отношениями с поставщиками, поддержка тендерных процедур, но бизнес-процесс приходования материалов — это стандартная функция ERP-системы, и соответственно его надо синхронизировать по структуре с ERP, иначе эти два продукта сложно будет интегрировать.
Александр Дудников: Я постоянно сталкиваюсь с проблемой интеграционной шины — и это действительно проблема во всех системах, с которыми приходится иметь дело. По большому счету ни в одной из существующих ERP-систем нет стандартной интеграционной шины, все время приходится что-то изобретать.
Алексей Нестеров: Сейчас у нас в роли такой шины часто выступает продукт «1С: Управление производственным предприятием», с которым синхронизированы десятки приложений — как специализированных, так и отраслевых. Но я не исключаю, что в будущем мы сможем создать или использовать более универсальную шину данных. И мне бы хотелось, чтобы существовал открытый стандарт для такой шины данных, чтобы самые разные приложения для управления бизнесом, поддерживающие этот стандарт, могли обмениваться между собой информацией без дополнительных работ. На мой взгляд, нас ждет такая же тенденция по шинам данных, как со стандартизацией электросетей и сетей связи.
Михаил Заборов: К сожалению, хотя первая версия стандарта электронного обмена данными — EDI — была опубликована тридцать лет назад, даже Metro Cash & Carry, которая по сути стояла у истоков создания EDI и до сих пор активно занимается этим стандартом, не сумела до конца наладить его использование. И я боюсь, что универсальная интеграционная шина — это неисполнимая мечта. Если реализовать ее как действительно универсальный механизм, ее сложность в общем случае будет превышать сложность подключенных к ней систем, и вы не сможете этой сложностью управлять.
Трансформировалось ли каким-либо образом за последнее время понятие отраслевого ERP-решения?
Алексей Нестеров: Я считаю, что да. Лет десять назад я замечал, что некоторые поставщики представляют, скажем, решение для пищевой промышленности и клиенты вроде бы реагируют положительно. Но мы подумали — разве может быть одно решение для мясокомбината, хлебозавода и ликеро-водочного завода? — и пошли по другому пути: создали три десятка узкоотраслевых ERP-решений. Сейчас мы видим, что не ошиблись: клиенты действительно предпочитают укрупненным «заготовкам» узкоспециализированные отраслевые решения.
Муза Монамс: Я собиралась сказать примерно то же самое. Мне кажется, специализация отраслевых решений становится более гибкой. Внутри любого такого решения должны быть широкие возможности настроек, изменений под данного клиента. Раньше компания SAP всем предлагала один и тот же набор «лучшего опыта», а теперь вынуждена менять свои акценты, потому что этого требуют клиенты, потому что нужно сокращать затраты, потому что растет специализация, потому что развивается рынок.
Юрий Ипатов: В советское время у нас были отраслевые министерства, которые развивали отраслевую науку и методологически ставили задачу. Сейчас отраслевыми решениями занимаются специалисты не по отрасли, а по автоматизации управления. Вместо отраслевой науки, которая существовала раньше, нам подсовывают нечто совершенно иное, и обобщенные отраслевые требования, таким образом, сейчас не вырабатываются.
Борис Аксёнов: Скорее происходит движение в обратном направлении. Разработчики создают модули — то есть они развивают систему, но развивают все равно конкретные модули. Если речь идет, скажем, о сбытовых функциях, то автоматизацию изначально не делают для транспорта или логистики. Если чего-то не хватает для конкретной отрасли — создают для нее модуль. Но это все равно будет модуль, а не отраслевая ERP-система.
Муза Монамс: Пожалуй, в качестве отраслевого ERP-решения нам стараются продать удачное внедрение продукта на каком-либо производстве. Именно оно часто и выдается, грубо говоря, за отраслевое решение.
Алексей Нестеров: Не всегда. Почти все наши отраслевые ERP-решения — это консолидированный опыт десятков, а иногда и сотен внедрений. Сейчас многие предприятия и холдинги вырабатывают методики вместо устаревших ведомственных инструкций, эти методики находят отражение при внедрении в доработках типовых ERP-систем и по мере накопления опыта реализуются в тиражных отраслевых решениях.
Муза Монамс: Кстати, у нас есть очень удачный опыт внедрения отраслевого решения SAP для издательств, из которого мы взяли только рекламный модуль. А секрет успеха, на мой взгляд, заключался в том, что мы купили решение «на вырост». Продажа рекламы — не главное на страницах нашего журнала, нам до полноценного использования модуля еще расти и расти, поэтому мы, уже несколько лет развиваясь в этом направлении, ещё не достали до «потолка» решения.
Некий парадокс заключается в том, что если бы этот же модуль внедряло рекламное издательство, которое, казалась бы, и является основным потребителем отраслевого решения, оно наверняка столкнулось бы с массой проблем. Почему? Потому что ему пришлось бы с самого начала использовать решение на сто процентов и, как следствие, иметь дело с ограничениями, неизбежными в любой системе.
Александр Дудников: По-моему, отраслевое решение не обязательно должно быть «на вырост». Мы пять лет назад внедрили такое решение, причем бельгийское, по управлению качеством, и оно замечательно работает в том же самом виде. Не понадобилось ни одной доработки, ни одного изменения.
За последние годы приобрели популярность — или даже практически сформировались с нуля — некоторые управленческие концепции, такие как бережливое производство, сервисная модель предоставления услуг, концепция Agile, краудсорсинг и многое другое. Что их появление означает для ERP?
Михаил Заборов: Что касается бережливого производства, то эта концепция, конечно, родилась именно в производстве, и она весьма старая, как и теория ограничений Голдратта, очень похожая на нее по философии, — это 1984 год. Сейчас она стала модной скорее всего потому, что ее пытаются применять в сфере услуг, таких как разработка заказного ПО, то есть не в классическом производстве.
Теперь — по поводу сервисной модели, технологии Agile и краудсорсинга. Изначально концепция ERP предполагала планирование сверху вниз: кто-то умный хорошо предвидит будущее — может быть, ему в этом помогают некие системы прогнозирования, — и строит долгосрочный план, на основе которого затем составляются планы на более короткие периоды, и по ним происходит работа. В случае ошибки система рушится — начинается подстройка планов, их изменение и прочее.
Если компания работает с конечным потребителем, она старается снять неопределенность, а для этого — наладить прямое взаимодействие с клиентами и более гибко реагировать на изменения ситуации. В результате система из «толкающей» (push) все больше превращается в «тянущую» (pull), и это меняет все алгоритмы MRP, рассчитанные на схему push.
Появляется много новых продуктов, которые надо быстро вывести на рынок, по которым надо быстро принять решение и что-то сделать. Тем самым ERP-система должна быть построена так, чтобы какие-то ее куски могли быстро меняться.
Муза Монамс: Мне непонятно, как пресловутая «турбулентность» бизнеса связана с ERP. Да, бизнес, как теперь часто говорят, турбулентен, а модели бизнеса у всех разные, но ERP-система по определению должна охватывать по крайней мере базовые функции, необходимые для работы предприятия. Подход Agile никогда не будет работать для больших предприятий, и он не может работать там, где существует фазовость процессов — если одну фазу начинают менять без учета других, это приводит как минимум к дисбалансу, а то и к хаосу. Так что мы должны локализовать применение подобных методов на очень небольшом и неглубоком функционале и ограничиться только развивающимися процессами. Agile — это стартап.
