Ситуационный расклад
Признаки неуспешных внедрений.
Причины неуспешных внедрений ERP
1. Модель самой 1С ERP
Первая причина - это модель, заложенная в саму 1С ERP (именно в 1С, а не в методику ERP вообще).
Проблема полуавтомата
Проблема многопараметричности
«Полуавтомат» модели 1С очень ярко выражается как раз через функционал, которым они очень гордятся – «диспетчирование» и через сценарии планирования.
Диспетчирование в 1С ERP выражается в том, что подача заданий на производство может быть задана вручную человеком - диспетчером. Получив отчёт-срез состояний загрузки оборудования, наличия материалов и т.п., проще говоря, получив срез ресурсов и имея список задач, человек может принять решение и перетасовать очередь работы оборудования (берите выше - всей компании) или вмешаться в результаты автоматического расчёта.
А теперь посмотрите, какой список параметров следует учесть, чтобы принять решение о запуске одного задания на производства (этапа производства):
- срез свободных мощностей на момент принятия решения и на период исполнения задания (список оборудования/персонала и их свободные слоты рабочего времени);
- наличие достаточных сырьевых ресурсов в производственной зоне (зона, где ресурс доступен исполнителю без значимой логистики доставки, т.е. «лежащее у станка»);
- сроки исполнения каждого задания из очереди всех заказов клиента (сроки поставки клиенту по заказу, сформировавшему задание);
- влияние на расчёт производственной программы и логистики заданий, одновременно поступивших в расчёт производственной загрузки, часть из которых может по итогам расчёта быть отвергнута как экономически невыгодные и/или невозможные к реализации по условиям исполнения.
Всё?
Для простого случая всё.
Но простым случаем будет всего три варианта:
1) Заказов (заданий) меньше, чем производственных мощностей (ресурсов) на их реализацию. Это случай, когда либо бизнес не выбирает все возможные сделки/заказы с рынка, либо бизнес имеет избыточные активы в данной сфере экономики;
2) В ходе задания на производство (этапа) выполняется одна простая операция;
3) Заказы (из которых формируются задания на производство) составляют стабильный неизменяемый список, объёмы, параметры изделия и сроки, однажды определенные, не изменяются.
Здесь 1С ERP и диспетчер с ручной подачей заданий справятся. Но, это при условии одновременного исполнения трёх вариантов, позволяющим считать случай «простым».
Но, если эта простая модель хоть немного усложняется в каком-то сегменте, то вся система усложняется в геометрической прогрессии. А теперь представьте, что диспетчер, отработав «прямой» ход операций, должен что-то скорректировать, т.е. выполнить обратный ход. Насколько сложно учесть громадный массив параметров, многие из которых скрылись в глубине регистров ERP?
Ниже на ментальной карте выведены верхнеуровневые параметры, которые должен держать в голове диспетчер (плановик, руководитель), пытающийся управлять заданиями на производство (этапами, выпуском, а руководитель ещё и всей экономикой от заказа клиента до логистики закупок).
Как видите, одновременный учёт всех этих параметров просто не под силу человеку. Какое бы он решение не принял по очереди заданий на производство, с высокой степенью вероятности оно не будет оптимальным, т.е. самым выгодным для предприятия. С такими расчётами может справиться только автоматизированный механизм с системой линейных уравнений и с целевой функцией и со сценарным проигрыванием.
Теперь смотрим внимательнее на схему и замечаем, что большинство параметров относятся не сколь к текущему моменту (слоту) времени, в котором «диспетчер» принимает решение, а описывают ситуацию с ещё не состоявшимися событиями, например:
- очередь заказов от клиентов;
- очередь заданий на производство по другим заказам;
- загрузка оборудования от сегодня и далее;
- загрузка и наличие персонала от сегодня и далее;
- остатки сырья сейчас и в каждый последующий слот времени = логистика;
- и т.д.
Таким образом, принимаемое решение по производственной программе должно размещаться в тех раскладах, которых нет в настоящем, но есть они в будущем, т.е. в планах, либо могут внезапно там появиться.
Отсюда следствие: ERP-система должна использовать блок планирования и с возможностью автоматической корректировки.
Теперь построим возражение на этот аргумент: «В 1С ERP есть функционал расчёта производственной программы (т.е. производственного планирования), поэтому можно обойтись без планирования на верхнем уровне (на уровне сделок)».
Обратимся снова к ментальной карте выше. Функционал 1С ERP по расчёту производственной программы не учитывает в этих блоках следующее:
1) В блоке «Финансы»
Факт неоплаты в срок (недостатка средств) – кассового разрыва.
Могут быть заключены все сделки по закупке сырья и услуг под заказ клиента, рассчитаны сроки поставки, но если какая-то поставка не будет оплачена в срок, то нередко есть вероятность, что движения по ней не будет.
Следствие: Расчёт производственной программы должен делаться не только с учётом наличия сырья в заданные моменты времени в будущем, но и от наличия необходимого остатка в заданные моменты времени в будущем. Причем не только остатков сырья, но и денежных средств. (Это, кстати говоря, можно сделать через «План остатков» системы планирования 1С ERP).
2) В блоке «События»
Ряд событий (сбой, брак, запреты и др.) создают «петли» движения ТМЦ. Например: необходимость дополнительных операций по дозакупке/переработке/переделке/переводу_в_сырьё брака. При этом переработка брака занимает ресурсы оборудования и конкурирует с вариантом закупки сырья вновь, но зато с более длительной логистикой доставки на склад.
А событие «Запрет» может создавать организационные ограничения на операции, хотя технологически их выполнить нет проблем.
Например, в химическом производстве (синтетических масел) может быть запрещено в отдельных реакторах варить дешёвое масло, а можно только дорогое. Хотя рядом в точно таком же реакторе дешёвое масло делается без проблем. Причина – необходимость промывки реактора и труб перед варкой дорого масла после дешёвого, а это затратная по ресурсу и времени операция.
Следствие:
- необходимы сложно-компонентные составные спецификации, в которых часть операций и входного сырья являются необходимыми в зависимости от предыдущего цикла производства.
- Производственное планирование должно учитывать качественные составляющие (запреты) предыдущего производственного цикла.
3) В блоке «Сложно-компонентные параметры на период»
Здесь как раз сокрыта проблема, происходящая из предыдущего пункта. В 1С ERP в настоящее время нет функционала, учитывающего историю предыдущих операций (циклов, партий), который определяет по какому варианту пойдут технологические и организационные процессы дальше.
4) В блоке «Производительность учётного ПО»
Здесь есть неявные параметры, которыми не может управлять производственник - «диспетчер».
Расчёт/пересчёт производственной программы очень ресурсоёмкий процесс и он необходим каждый раз при смене любого параметра из схемы, хотя бы даже одного. При этом, в немалом количестве случаев такой расчёт должен выполняться задолго до того как вступит в работу производственник (диспетчер).
Самый частый пример подобного на практике - в позаказном варианте работы предприятия, когда в момент заявки клиента на исполнение заказа необходимо рассчитать, возможно ли исполнение заказа в желаемые клиентом срок, прочие параметры и по какой стоимости. Расчёт может показать отсутствие временных слотов на исполнение в желаемый клиентом срок или высокую стоимость исполнения в желаемый срок или необходимость существенного сдвига очереди других заказов. Для исполнения такого расчёта нужно, как минимум сценарное планирование, позволяющее вернуть состояние предыдущего расчёта, если текущий обсчитываемый заказ не принимается в работу.
Здесь речь идёт не только о производительности кода ERP (зачастую «допиленного») и серверов, а даже о потенциальной ресурсоёмкости функционала расчёта системы линейных уравнений, необходимого для подобных расчётов в ERP. Не зря для многих производственных, особенно оборонных, машиностроительных компаний, после внедрения УПП/ERP внезапно (удивительно, да?) встаёт проблема ресурсоёмкости пересчёта производственных программ. Для чего начинают смотреть в сторону специальных продуктов типа Siemens Preactor и/или «чистого SQL». А тут ещё санкции и расцвет «дружбы» с Европой и прочими Америками. В самой ERP нужно дорабатывать этот функционал объёмным кодом и не факт что средствами платформы 1С.
Проблемы отсутствия сценарных расчетов.
Проблемы НСИ и спецификаций.
Проблемы перепроведения.
- Технология внедрения и сопровождения ERP
Теперь смотрим, какая вторая причина, гарантирующая неуспешность внедрения ERP. Она действовала ещё при внедрении УПП лет 15 назад!
- Неавтоматизированное управление бизнес-процессами
Выше по тексту статьи отсутствие автоматизации управления бизнес-процессами называлось признаком неуспешности внедрения ERP. Теперь же покажем, что это также является и одной из причин.
Причины неуспешных внедрений ERP
1. Модель самой 1С ERP
Первая причина - это модель, заложенная в саму 1С ERP (именно в 1С, а не в методику ERP вообще).
Проблема полуавтомата
Проблема многопараметричности
«Полуавтомат» модели 1С очень ярко выражается как раз через функционал, которым они очень гордятся – «диспетчирование» и через сценарии планирования.
Диспетчирование в 1С ERP выражается в том, что подача заданий на производство может быть задана вручную человеком - диспетчером. Получив отчёт-срез состояний загрузки оборудования, наличия материалов и т.п., проще говоря, получив срез ресурсов и имея список задач, человек может принять решение и перетасовать очередь работы оборудования (берите выше - всей компании) или вмешаться в результаты автоматического расчёта.
А теперь посмотрите, какой список параметров следует учесть, чтобы принять решение о запуске одного задания на производства (этапа производства):
- срез свободных мощностей на момент принятия решения и на период исполнения задания (список оборудования/персонала и их свободные слоты рабочего времени);
- наличие достаточных сырьевых ресурсов в производственной зоне (зона, где ресурс доступен исполнителю без значимой логистики доставки, т.е. «лежащее у станка»);
- сроки исполнения каждого задания из очереди всех заказов клиента (сроки поставки клиенту по заказу, сформировавшему задание);
- влияние на расчёт производственной программы и логистики заданий, одновременно поступивших в расчёт производственной загрузки, часть из которых может по итогам расчёта быть отвергнута как экономически невыгодные и/или невозможные к реализации по условиям исполнения.
Всё?
Для простого случая всё.
Но простым случаем будет всего три варианта:
1) Заказов (заданий) меньше, чем производственных мощностей (ресурсов) на их реализацию. Это случай, когда либо бизнес не выбирает все возможные сделки/заказы с рынка, либо бизнес имеет избыточные активы в данной сфере экономики;
2) В ходе задания на производство (этапа) выполняется одна простая операция;
3) Заказы (из которых формируются задания на производство) составляют стабильный неизменяемый список, объёмы, параметры изделия и сроки, однажды определенные, не изменяются.
Здесь 1С ERP и диспетчер с ручной подачей заданий справятся. Но, это при условии одновременного исполнения трёх вариантов, позволяющим считать случай «простым».
Но, если эта простая модель хоть немного усложняется в каком-то сегменте, то вся система усложняется в геометрической прогрессии. А теперь представьте, что диспетчер, отработав «прямой» ход операций, должен что-то скорректировать, т.е. выполнить обратный ход. Насколько сложно учесть громадный массив параметров, многие из которых скрылись в глубине регистров ERP?
Ниже на ментальной карте выведены верхнеуровневые параметры, которые должен держать в голове диспетчер (плановик, руководитель), пытающийся управлять заданиями на производство (этапами, выпуском, а руководитель ещё и всей экономикой от заказа клиента до логистики закупок).
Как видите, одновременный учёт всех этих параметров просто не под силу человеку. Какое бы он решение не принял по очереди заданий на производство, с высокой степенью вероятности оно не будет оптимальным, т.е. самым выгодным для предприятия. С такими расчётами может справиться только автоматизированный механизм с системой линейных уравнений и с целевой функцией и со сценарным проигрыванием.
Теперь смотрим внимательнее на схему и замечаем, что большинство параметров относятся не сколь к текущему моменту (слоту) времени, в котором «диспетчер» принимает решение, а описывают ситуацию с ещё не состоявшимися событиями, например:
- очередь заказов от клиентов;
- очередь заданий на производство по другим заказам;
- загрузка оборудования от сегодня и далее;
- загрузка и наличие персонала от сегодня и далее;
- остатки сырья сейчас и в каждый последующий слот времени = логистика;
- и т.д.
Таким образом, принимаемое решение по производственной программе должно размещаться в тех раскладах, которых нет в настоящем, но есть они в будущем, т.е. в планах, либо могут внезапно там появиться.
Отсюда следствие: ERP-система должна использовать блок планирования и с возможностью автоматической корректировки.
Теперь построим возражение на этот аргумент: «В 1С ERP есть функционал расчёта производственной программы (т.е. производственного планирования), поэтому можно обойтись без планирования на верхнем уровне (на уровне сделок)».
Обратимся снова к ментальной карте выше. Функционал 1С ERP по расчёту производственной программы не учитывает в этих блоках следующее:
1) В блоке «Финансы»
Факт неоплаты в срок (недостатка средств) – кассового разрыва.
Могут быть заключены все сделки по закупке сырья и услуг под заказ клиента, рассчитаны сроки поставки, но если какая-то поставка не будет оплачена в срок, то нередко есть вероятность, что движения по ней не будет.
Следствие: Расчёт производственной программы должен делаться не только с учётом наличия сырья в заданные моменты времени в будущем, но и от наличия необходимого остатка в заданные моменты времени в будущем. Причем не только остатков сырья, но и денежных средств. (Это, кстати говоря, можно сделать через «План остатков» системы планирования 1С ERP).
2) В блоке «События»
Ряд событий (сбой, брак, запреты и др.) создают «петли» движения ТМЦ. Например: необходимость дополнительных операций по дозакупке/переработке/переделке/переводу_в_сырьё брака. При этом переработка брака занимает ресурсы оборудования и конкурирует с вариантом закупки сырья вновь, но зато с более длительной логистикой доставки на склад.
А событие «Запрет» может создавать организационные ограничения на операции, хотя технологически их выполнить нет проблем.
Например, в химическом производстве (синтетических масел) может быть запрещено в отдельных реакторах варить дешёвое масло, а можно только дорогое. Хотя рядом в точно таком же реакторе дешёвое масло делается без проблем. Причина – необходимость промывки реактора и труб перед варкой дорого масла после дешёвого, а это затратная по ресурсу и времени операция.
Следствие:
- необходимы сложно-компонентные составные спецификации, в которых часть операций и входного сырья являются необходимыми в зависимости от предыдущего цикла производства.
- Производственное планирование должно учитывать качественные составляющие (запреты) предыдущего производственного цикла.
3) В блоке «Сложно-компонентные параметры на период»
Здесь как раз сокрыта проблема, происходящая из предыдущего пункта. В 1С ERP в настоящее время нет функционала, учитывающего историю предыдущих операций (циклов, партий), который определяет по какому варианту пойдут технологические и организационные процессы дальше.
4) В блоке «Производительность учётного ПО»
Здесь есть неявные параметры, которыми не может управлять производственник - «диспетчер».
Расчёт/пересчёт производственной программы очень ресурсоёмкий процесс и он необходим каждый раз при смене любого параметра из схемы, хотя бы даже одного. При этом, в немалом количестве случаев такой расчёт должен выполняться задолго до того как вступит в работу производственник (диспетчер).
Самый частый пример подобного на практике - в позаказном варианте работы предприятия, когда в момент заявки клиента на исполнение заказа необходимо рассчитать, возможно ли исполнение заказа в желаемые клиентом срок, прочие параметры и по какой стоимости. Расчёт может показать отсутствие временных слотов на исполнение в желаемый клиентом срок или высокую стоимость исполнения в желаемый срок или необходимость существенного сдвига очереди других заказов. Для исполнения такого расчёта нужно, как минимум сценарное планирование, позволяющее вернуть состояние предыдущего расчёта, если текущий обсчитываемый заказ не принимается в работу.
Здесь речь идёт не только о производительности кода ERP (зачастую «допиленного») и серверов, а даже о потенциальной ресурсоёмкости функционала расчёта системы линейных уравнений, необходимого для подобных расчётов в ERP. Не зря для многих производственных, особенно оборонных, машиностроительных компаний, после внедрения УПП/ERP внезапно (удивительно, да?) встаёт проблема ресурсоёмкости пересчёта производственных программ. Для чего начинают смотреть в сторону специальных продуктов типа Siemens Preactor и/или «чистого SQL». А тут ещё санкции и расцвет «дружбы» с Европой и прочими Америками. В самой ERP нужно дорабатывать этот функционал объёмным кодом и не факт что средствами платформы 1С.
Проблемы отсутствия сценарных расчетов.
Проблемы НСИ и спецификаций.
Проблемы перепроведения.
- Технология внедрения и сопровождения ERP
Теперь смотрим, какая вторая причина, гарантирующая неуспешность внедрения ERP. Она действовала ещё при внедрении УПП лет 15 назад!
- Неавтоматизированное управление бизнес-процессами
Выше по тексту статьи отсутствие автоматизации управления бизнес-процессами называлось признаком неуспешности внедрения ERP. Теперь же покажем, что это также является и одной из причин.
1. Модель самой 1С ERP
Первая причина - это модель, заложенная в саму 1С ERP (именно в 1С, а не в методику ERP вообще).
Проблема полуавтомата
Проблема многопараметричности
«Полуавтомат» модели 1С очень ярко выражается как раз через функционал, которым они очень гордятся – «диспетчирование» и через сценарии планирования.
Диспетчирование в 1С ERP выражается в том, что подача заданий на производство может быть задана вручную человеком - диспетчером. Получив отчёт-срез состояний загрузки оборудования, наличия материалов и т.п., проще говоря, получив срез ресурсов и имея список задач, человек может принять решение и перетасовать очередь работы оборудования (берите выше - всей компании) или вмешаться в результаты автоматического расчёта.
А теперь посмотрите, какой список параметров следует учесть, чтобы принять решение о запуске одного задания на производства (этапа производства):
- срез свободных мощностей на момент принятия решения и на период исполнения задания (список оборудования/персонала и их свободные слоты рабочего времени);
- наличие достаточных сырьевых ресурсов в производственной зоне (зона, где ресурс доступен исполнителю без значимой логистики доставки, т.е. «лежащее у станка»);
- сроки исполнения каждого задания из очереди всех заказов клиента (сроки поставки клиенту по заказу, сформировавшему задание);
- влияние на расчёт производственной программы и логистики заданий, одновременно поступивших в расчёт производственной загрузки, часть из которых может по итогам расчёта быть отвергнута как экономически невыгодные и/или невозможные к реализации по условиям исполнения.
Всё?
Для простого случая всё.
Но простым случаем будет всего три варианта:
1) Заказов (заданий) меньше, чем производственных мощностей (ресурсов) на их реализацию. Это случай, когда либо бизнес не выбирает все возможные сделки/заказы с рынка, либо бизнес имеет избыточные активы в данной сфере экономики;
2) В ходе задания на производство (этапа) выполняется одна простая операция;
3) Заказы (из которых формируются задания на производство) составляют стабильный неизменяемый список, объёмы, параметры изделия и сроки, однажды определенные, не изменяются.
Здесь 1С ERP и диспетчер с ручной подачей заданий справятся. Но, это при условии одновременного исполнения трёх вариантов, позволяющим считать случай «простым».
Но, если эта простая модель хоть немного усложняется в каком-то сегменте, то вся система усложняется в геометрической прогрессии. А теперь представьте, что диспетчер, отработав «прямой» ход операций, должен что-то скорректировать, т.е. выполнить обратный ход. Насколько сложно учесть громадный массив параметров, многие из которых скрылись в глубине регистров ERP?
Ниже на ментальной карте выведены верхнеуровневые параметры, которые должен держать в голове диспетчер (плановик, руководитель), пытающийся управлять заданиями на производство (этапами, выпуском, а руководитель ещё и всей экономикой от заказа клиента до логистики закупок).
Как видите, одновременный учёт всех этих параметров просто не под силу человеку. Какое бы он решение не принял по очереди заданий на производство, с высокой степенью вероятности оно не будет оптимальным, т.е. самым выгодным для предприятия. С такими расчётами может справиться только автоматизированный механизм с системой линейных уравнений и с целевой функцией и со сценарным проигрыванием.
Теперь смотрим внимательнее на схему и замечаем, что большинство параметров относятся не сколь к текущему моменту (слоту) времени, в котором «диспетчер» принимает решение, а описывают ситуацию с ещё не состоявшимися событиями, например:
- очередь заказов от клиентов;
- очередь заданий на производство по другим заказам;
- загрузка оборудования от сегодня и далее;
- загрузка и наличие персонала от сегодня и далее;
- остатки сырья сейчас и в каждый последующий слот времени = логистика;
- и т.д.
Таким образом, принимаемое решение по производственной программе должно размещаться в тех раскладах, которых нет в настоящем, но есть они в будущем, т.е. в планах, либо могут внезапно там появиться.
Отсюда следствие: ERP-система должна использовать блок планирования и с возможностью автоматической корректировки.
Теперь построим возражение на этот аргумент: «В 1С ERP есть функционал расчёта производственной программы (т.е. производственного планирования), поэтому можно обойтись без планирования на верхнем уровне (на уровне сделок)».
Обратимся снова к ментальной карте выше. Функционал 1С ERP по расчёту производственной программы не учитывает в этих блоках следующее:
1) В блоке «Финансы»
Факт неоплаты в срок (недостатка средств) – кассового разрыва.
Могут быть заключены все сделки по закупке сырья и услуг под заказ клиента, рассчитаны сроки поставки, но если какая-то поставка не будет оплачена в срок, то нередко есть вероятность, что движения по ней не будет.
Следствие: Расчёт производственной программы должен делаться не только с учётом наличия сырья в заданные моменты времени в будущем, но и от наличия необходимого остатка в заданные моменты времени в будущем. Причем не только остатков сырья, но и денежных средств. (Это, кстати говоря, можно сделать через «План остатков» системы планирования 1С ERP).
2) В блоке «События»
Ряд событий (сбой, брак, запреты и др.) создают «петли» движения ТМЦ. Например: необходимость дополнительных операций по дозакупке/переработке/переделке/переводу_в_сырьё брака. При этом переработка брака занимает ресурсы оборудования и конкурирует с вариантом закупки сырья вновь, но зато с более длительной логистикой доставки на склад.
А событие «Запрет» может создавать организационные ограничения на операции, хотя технологически их выполнить нет проблем.
Например, в химическом производстве (синтетических масел) может быть запрещено в отдельных реакторах варить дешёвое масло, а можно только дорогое. Хотя рядом в точно таком же реакторе дешёвое масло делается без проблем. Причина – необходимость промывки реактора и труб перед варкой дорого масла после дешёвого, а это затратная по ресурсу и времени операция.
Следствие:
- необходимы сложно-компонентные составные спецификации, в которых часть операций и входного сырья являются необходимыми в зависимости от предыдущего цикла производства.
- Производственное планирование должно учитывать качественные составляющие (запреты) предыдущего производственного цикла.
3) В блоке «Сложно-компонентные параметры на период»
Здесь как раз сокрыта проблема, происходящая из предыдущего пункта. В 1С ERP в настоящее время нет функционала, учитывающего историю предыдущих операций (циклов, партий), который определяет по какому варианту пойдут технологические и организационные процессы дальше.
4) В блоке «Производительность учётного ПО»
Здесь есть неявные параметры, которыми не может управлять производственник - «диспетчер».
Расчёт/пересчёт производственной программы очень ресурсоёмкий процесс и он необходим каждый раз при смене любого параметра из схемы, хотя бы даже одного. При этом, в немалом количестве случаев такой расчёт должен выполняться задолго до того как вступит в работу производственник (диспетчер).
Самый частый пример подобного на практике - в позаказном варианте работы предприятия, когда в момент заявки клиента на исполнение заказа необходимо рассчитать, возможно ли исполнение заказа в желаемые клиентом срок, прочие параметры и по какой стоимости. Расчёт может показать отсутствие временных слотов на исполнение в желаемый клиентом срок или высокую стоимость исполнения в желаемый срок или необходимость существенного сдвига очереди других заказов. Для исполнения такого расчёта нужно, как минимум сценарное планирование, позволяющее вернуть состояние предыдущего расчёта, если текущий обсчитываемый заказ не принимается в работу.
Здесь речь идёт не только о производительности кода ERP (зачастую «допиленного») и серверов, а даже о потенциальной ресурсоёмкости функционала расчёта системы линейных уравнений, необходимого для подобных расчётов в ERP. Не зря для многих производственных, особенно оборонных, машиностроительных компаний, после внедрения УПП/ERP внезапно (удивительно, да?) встаёт проблема ресурсоёмкости пересчёта производственных программ. Для чего начинают смотреть в сторону специальных продуктов типа Siemens Preactor и/или «чистого SQL». А тут ещё санкции и расцвет «дружбы» с Европой и прочими Америками. В самой ERP нужно дорабатывать этот функционал объёмным кодом и не факт что средствами платформы 1С.
Проблемы отсутствия сценарных расчетов.
Проблемы НСИ и спецификаций.
Проблемы перепроведения.
Теперь смотрим, какая вторая причина, гарантирующая неуспешность внедрения ERP. Она действовала ещё при внедрении УПП лет 15 назад!
Выше по тексту статьи отсутствие автоматизации управления бизнес-процессами называлось признаком неуспешности внедрения ERP. Теперь же покажем, что это также является и одной из причин.
Резюме
PS
В случае интереса пользователей возможна публикация статей по темам:
- Структура минимально необходимой команды по сопровождению ERP.
- Как описать карту доступа пользователей к ERP и иным системам 1С в ландшафте компаний с помощью 1С СППР.
