Почему внедрение ERP не улучшает управляемость бизнеса

Когда на предприятии говорят: «Мы внедрили ERP-систему», это обычно звучит как завершенная история. Проект закончен, люди работают, учет идет, отчетность формируется. Но если говорить честно, для многих компаний именно в этот момент все только начинается.

Почему ERP не оправдывает ожиданий

Я работаю с автоматизацией и финансовым контуром предприятий АПК и FMCG – от зарплаты и регламентированного учета до бюджетирования, казначейства и планирования затрат. И слишком часто вижу одну и ту же ситуацию: система планирования ресурсов формально внедрена, а полноценным инструментом управления так и не стала. В глубинных интервью с предприятиями ситуация подтверждается.

Система есть. Данных много. Процессы вроде бы заведены. Но как только разговор заходит о реальной пользе для бизнеса, интонация меняется. Выясняется:

  • Что отчеты по-прежнему собирают руками.
  • Себестоимость считается поздно.
  • Бюджеты живут отдельно, казначейство – отдельно.
  • У руководителей нет спокойной уверенности, что цифрам в системе можно доверять как опоре для управленческих решений.

Кто-то сразу говорит, что в системе полно недоделок, с кем-то мы приходим к такому выводу в процессе диалога. Многие стыдятся, что потратили деньги и время, а результата не получили. Чувствуют себя, прямо скажем, проигравшими.

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

Одна из самых недооцененных проблем вокруг ERP: компания прошла тяжелый проект, потратила деньги, время, ресурс команды, а эффект оказался слабее, чем ожидалось. Не потому, что решение не работает. И не потому, что «сделали плохо». Чаще причина в другом: проект был завершен как IT-переход, но не состоялся как переход к новой управленческой модели.

Разумеется, это не повод впадать в оправдательную позицию и, как школьники, сетовать, что «весь класс эту контрольную на двойки написал». Поэтому возвращаемся к извечному вопросу «Что делать?»:

  1. Разобрать причины неудовлетворительного результата (чтобы больше так не делать).
  2. Понять саму его суть – что конкретно не устраивает.
  3. Уже после этого разрабатывать план исправления ситуации.

В этом материале хочу поговорить о первых двух шагах, чтобы во всей боевой готовности подойти к третьему.

Причины недовольства ERP-системой

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

1. Проект начинали как технический переход, а не как бизнес-задачу

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

2. Проект делали быстро, и скорость стала важнее качества результата

ERP-проект почти всегда наказывает за спешку – не в день запуска, а позже. Если долго собираться, поздно стартовать или до последнего тянуть с решениями, дальше все подчиняется одному вопросу: успеем или нет. Особенно, если на горизонте сдача регламентированной отчетности, жесткие сроки или давление со стороны руководства.

В этот момент качество начинает пониматься очень узко. Хорошо – это когда запустились. Плохо – когда не запустились. Остальное считается вторичным. Поэтому что-то упрощают, что-то вырезают, что-то откладывают, что-то переносят в новую систему почти в неизменном виде, лишь бы не рисковать сроками. Именно так в ERP попадают будущие ограничения. Не как ошибка одного человека, а как цепочка рациональных, но коротких решений.

3. Подрядчик мог быть в стадии обучения

Российский рынок ERP-внедрений не всегда был зрелым. Многие ранние проекты запускались в тот момент, когда участники, по сути, учились на ходу. Заказчик делал это впервые. Подрядчик часто тоже впервые сталкивался со сложностью отрасли, требованиями регуляторов или масштабом бизнеса. В результате обе стороны проходили через ошибки вместе.

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

4. В новую систему переносили все, что было в старой

Мотивация заказчика здесь понятна: «Давайте сделаем хотя бы не хуже, чем было». Особенно это характерно для переходов с УПП. Компании настолько боятся потерять привычный контур, что стараются перенести в новую систему все – логику, процессы, исключения, обходные пути, привычки пользователей, старые отчеты, старые подходы к данным.

Но ERP – это другой продукт с иной логикой. Здесь другие возможности и ограничения. Когда решение используют как новую оболочку для старой системы мышления, получается ровно то, что потом раздражает сильнее всего: вроде бы внедрили современный инструмент, а по ощущениям получили ту же УПП, только в профиль.

5. Сделали минимум и решили, что этого достаточно

Для старта минимальный объем – нормальный подход, даже разумный. Не всегда нужно пытаться охватить все сразу.

Здесь важно сделать оговорку. Не каждый ERP-проект обязан сразу стать полноценным ядром управления, и не для каждой компании это реалистичная цель на первом этапе. Иногда минимальный контур – рациональный выбор: важнее сначала стабилизировать учет, пройти переход без сбоев, и только потом расширять функциональную роль системы.

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

Что происходит после внедрения ERP

И вот проект завершен. Люди начинают работать в новой системе – какой есть. Дальше обычно начинается показательная стадия. Пользователи сталкиваются с ограничениями, руководители – с неудобными вопросами, финансовая функция – с ручным трудом. Ожидаемого скачка в управляемости не произошло.

Что делает большинство компаний в этот момент? Ничего. И не потому, что всех все устраивает. Просто сама мысль о том, что систему надо дорабатывать, часто воспринимается как угроза нового большого проекта: снова деньги, снова напряжение, снова длинный цикл согласований, снова неудобный разговор с руководством. Я не раз слышала примерно такую логику: мы уже вложились, признать, что эффект не тот, значит, открыть неприятную тему заново. Проще привыкнуть. Приспособиться. Научиться жить с тем, что есть.

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

На что жалуются пользователи ERP-систем

Набор претензий довольно предсказуем, и повторяется из проекта в проект:

  • «Система не дала нам ничего принципиально нового». Это обидно, но спорить трудно. Формально система есть. Но бизнес-ценности сверх самого перехода не появилось. Обычно это означает, что заказчик не сформулировал, какую именно управленческую разницу должна дать новая ERP. Надеялись, что платформа сама по себе окажется полезной. Но это так не работает. Если не задать системе новую роль в управлении, она просто закрепит старую.
  • «Кроме учета, почти ничего не автоматизировано». Когда ERP воспринимается, прежде всего, как инструмент организации учета, это почти неизбежный сценарий. В первую очередь закрывают регламентированный контур. Остальное (бюджетирование, казначейство, лимиты, платежный календарь, контроль отклонений, планирование затрат) остается на потом. И это пресловутое «потом», бывает, так и не наступает. На старте это выглядит как разумная приоритизация. В повседневной работе – как постоянная управленческая недостача. Потому что платежи продолжают согласовываться в почте, часть финансовой логики живет в Excel, а система не помогает ни вовремя увидеть кассовый разрыв, ни отследить перерасход по статье.
  • «Ручной труд никуда не исчез». Болезненная история. Особенно, когда на старте ожидания были почти магические: внедрим ERP, и система начнет сама собирать, считать, подсказывать, предупреждать. В одном из производственных проектов финансовая команда спустя несколько месяцев после запуска продолжала собирать часть управленческой отчетности вручную, просто потому, что в системе не было той аналитики, на которую реально опирался бизнес. Формально ERP была внедрена. По факту сотрудники каждый месяц возвращались к таблицам, чтобы «дособрать картину» для принятия решений. Итого, система уже есть, но управленческая реальность все еще живет вне нее.
  • «Себестоимость считается долго и без нужной детализации». Для АПК и FMCG это не просто техническое неудобство, а риск плохих решений. Если себестоимость видна поздно, если детализация недостаточна, если косвенные затраты распределяются грубо, бизнес теряет возможность видеть реальную экономику продукта, когда еще можно на что-то влиять. А когда маржинальность понятна постфактум, управление начинает запаздывать вместе с ней.
  • «Не верю!» – самый тревожный симптом. Пока ERP воспринимается как обязательный контур, но не как источник достоверной управленческой информации, бизнес всегда будет держать внутреннюю дистанцию. Формально отчетность в системе есть. Но если при анализе прибыли, планировании закупок или принятии финансовых решений команда все равно считает, что «эти цифры нужно перепроверить», значит, система не стала настоящей опорой управления. А без доверия к данным никакая ERP не превращается в ядро бизнеса.

Почему ERP надо внедрять не как IT-решение, а инструмент управления

Где на самом деле лежит граница между внедрением и реальным результатом? Здесь важно уйти от черно-белой логики. ERP-проект необязательно либо провальный, либо успешный. В реальности большинство историй находятся где-то посередине. Команда смогла проделать колоссальную работу: перейти на новую платформу, выстроить базовый контур, стабилизировать учет, обучить пользователей, запустить ключевые процессы. Это серьезный результат, но это не равно автоматически управленческому эффекту. Именно здесь проходит граница, которую часто не проговаривают вслух: система может быть внедрена как IT-продукт, но не состояться как инструмент управления. Это – главная разница.

Важно понять:

  • Сам факт запуска еще ничего не доказывает. Да, пройден важный и дорогой инфраструктурный этап. Но это не значит, что бизнес после этого стал управляться лучше.
  • Если ERP не стала тем ядром управления, на которое рассчитывали, это еще не повод объявлять проект провалом. Но нужно честно посмотреть на разрыв между формальным внедрением и реальным эффектом.

Здесь полезно задавать себе не технические, а управленческие вопросы:

  • Какие задачи система реально закрывает, а какие – только на бумаге?
  • Где компания по-прежнему живет в ручном контуре?
  • В каких точках решения принимаются с ограниченной видимостью?
  • Каким данным в ERP доверяют, а каким – нет?
  • Что в системе стало инструментом управления, а что осталось просто обязательной инфраструктурой?

Пока эти вопросы не заданы честно, разговор о результате внедрения остается слишком декоративным.

Выводы

ERP редко разочаровывает сразу. Чаще система постепенно показывает – насколько компания была готова менять не только решение, но и собственную управленческую логику. Если этот масштаб оказался меньше ожиданий, проблема, как правило, не в продукте. Проблема в том, что проект закончился раньше, чем началось настоящее движение к управляемости.

Также читайте:

Расскажите коллегам:
Комментарии
Борис Кондрабаев пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Главный вопрос в том, что представитель заказчика может не иметь компетенций или полномочий по улучшению труда пользователей на разных рабочих местах. Он заказывает ПО для компании! 

Как правило рабочие места делятся по ролям пользователя. Роли прописываются в ТЗ. Это если мы ставим автоматизированную систему. В хороших системах и роли могут настраиваться и добавляться.

Типичные роли: руководитель, админ, пользователь. Но это далеко не конечный список.

Совсем не вижу здесь проблем. 

Я бы начал с функционала и требований к нему. Кто-то думает над сценариями. Из них вытекают роли и всё, что с ними связано. 

Если заказчик понимает, что он хочет получить в итоге - проблемы не будет. Или это можно сделать, или нет. А дальше всё идёт в соответствии с жизненным циклом системы.

Логика подходящая, особенно если добавить задачи создания удобств для пользователей для повышения производительности.

При этом производительность это как пользователям меньшими усилиями делать быстрее или больше работ!

Каких именно работ?

Просто так или по наитию в корпоративной системе никто никаких работ не делает. Для всего нужны права доступа и функционал в соответствии с поддерживаемым системой процессом и сценарием для этого рабочего места.

Корпоративные системы категории ERP с несколькими функциональными модулями (иногда 10+) и соответствующими структурами данных, к примеру, могут поддерживать эффективное решение сотен различных задач одновременно для тысяч и десятков тысяч пользователей. Таких примеров достаточно.

Быстрее или больше - не критерий. Важно правильно и в срок. Без повторов, петель, лишних циклов, исправлений и переделок. Деньги обычно теряются именно на этом.

Почему, собственно, не очень понятно, о чём на самом деле написана статья.

Сергей Попов пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Главный вопрос в том, что представитель заказчика может не иметь компетенций или полномочий по улучшению труда пользователей на разных рабочих местах. Он заказывает ПО для компании! 

Как правило рабочие места делятся по ролям пользователя. Роли прописываются в ТЗ. Это если мы ставим автоматизированную систему. В хороших системах и роли могут настраиваться и добавляться.

Типичные роли: руководитель, админ, пользователь. Но это далеко не конечный список.

Совсем не вижу здесь проблем. 

Я бы начал с функционала и требований к нему. Кто-то думает над сценариями. Из них вытекают роли и всё, что с ними связано. 

Если заказчик понимает, что он хочет получить в итоге - проблемы не будет. Или это можно сделать, или нет. А дальше всё идёт в соответствии с жизненным циклом системы.

интересная статья, но к сожалению, у меня нет опыта внедрения или эксплуатации ЕРП. Но начало обсуждения, и вот этот Ваш пост постоянно возвращали меня к мысли именно о "Функционале". На кой чёрт нам нужен этот дорогущий продукт?! Какие вопросы он поможет нам решить?

Да. И это самое главное.

Дело не в ERP, ПО и вообще не о технике. Речь об изменениях. Потратили деньги, время, силы, сделали это вместо другого. Зачем? Что хотели-то? Где были, куда пришли?

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

Эти вопросы стоят тех денег, которые с нас слупят в результате установки и пожизненного сопровождения? Чаще всего, мы даже не представляем себе, во что ввязываемся.

Так и есть. Это, скорее, нормально.

"Мы" - тут я и себя вплёл )) Всё же, мы меняли Автоматизированную банковскую систему. Одну на другую, да ещё на платформе Оракл. Консультанты и внутренние лоббисты говорили, что "всё будетлетать!". Я до сих пор не могу понять, ЧТО должно было лететь и куда. Да, какие-то бизнес - операции стали проводить, но потом приходилось каждый новый модуль или внесение изменений из-за изменившегося законодательства покупать снова.

С внутренними лоббистами бороться сложно, но зависит от того, кем Вы себя видите.

А всё остальное решается на уровне проекта. Иногда даже тестирование в песочнице или опытная эксплуатация в ограниченном объёме существенно меняет представления о возможном.

Вся банковская система России сидела на нескольких разработчиках, как на игле. И сейчас сидят...

Да, про функционал... :)) Читаю и думаю, как мне купить телефон без всех этих наворотов и обязательных приложений? Я не знаю, может быть, кто-то использует хотя бы половину всех возможностей телефона? ЭТо половвина функций не нужна? Она же оплачена?

В стандартных продуктах покупатель оплачивает всё, что авторам пришло в голову. А завтра этого будет еще больше.

Если на торте 25 розочек, придётся заплатить. Со временем количество лишнего и ненужного (тебе) начинает удивлять, а потом перестаёт.

Да, я и в машине не все функции выучил :)) 

Сколько кнопок на пульте у Вашего телевизора?

Что там люди от ЕРП недополучают? Главную книгу ведёт - и Ладно!)))

Захотят - расскажут. Двух одинаковых инсталляций ERP, практически уверен, не существует.

Евгений Равич пишет:
Борис Кондрабаев пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Главный вопрос в том, что представитель заказчика может не иметь компетенций или полномочий по улучшению труда пользователей на разных рабочих местах. Он заказывает ПО для компании! 

Как правило рабочие места делятся по ролям пользователя. Роли прописываются в ТЗ. Это если мы ставим автоматизированную систему. В хороших системах и роли могут настраиваться и добавляться.

Типичные роли: руководитель, админ, пользователь. Но это далеко не конечный список.

Совсем не вижу здесь проблем. 

Я бы начал с функционала и требований к нему. Кто-то думает над сценариями. Из них вытекают роли и всё, что с ними связано. 

Если заказчик понимает, что он хочет получить в итоге - проблемы не будет. Или это можно сделать, или нет. А дальше всё идёт в соответствии с жизненным циклом системы.

Логика подходящая, особенно если добавить задачи создания удобств для пользователей для повышения производительности.

При этом производительность это как пользователям меньшими усилиями делать быстрее или больше работ!

Каких именно работ?

Просто так или по наитию в корпоративной системе никто никаких работ не делает. Для всего нужны права доступа и функционал в соответствии с поддерживаемым системой процессом и сценарием для этого рабочего места.

Корпоративные системы категории ERP с несколькими функциональными модулями (иногда 10+) и соответствующими структурами данных, к примеру, могут поддерживать эффективное решение сотен различных задач одновременно для тысяч и десятков тысяч пользователей. Таких примеров достаточно.

Быстрее или больше - не критерий. Важно правильно и в срок. Без повторов, петель, лишних циклов, исправлений и переделок. Деньги обычно теряются именно на этом.

Почему, собственно, не очень понятно, о чём на самом деле написана статья.

Евгений, Вы удивляете вопросом о том какие работы могут быть в корпорации, а затем отражаться в ПО.

С учетом того что происходит на самом деле для того чтобы выполнять намеченные планы как раз и нужны "быстрее и больше"!

Или Вы знаете такие компании где все и всегда идет так как было намечено первоначальным планом?

Я правда принимаю также во внимание что платежеспособных заказов может быть больше и планы могут изменяться в связи с изменением рыночного спроса!

В Вашей концепции планы должны быть низкими чтобы точно исполнимыми или возможны увеличения?

Борис Кондрабаев пишет:
Евгений Равич пишет:
Борис Кондрабаев пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Главный вопрос в том, что представитель заказчика может не иметь компетенций или полномочий по улучшению труда пользователей на разных рабочих местах. Он заказывает ПО для компании! 

Как правило рабочие места делятся по ролям пользователя. Роли прописываются в ТЗ. Это если мы ставим автоматизированную систему. В хороших системах и роли могут настраиваться и добавляться.

Типичные роли: руководитель, админ, пользователь. Но это далеко не конечный список.

Совсем не вижу здесь проблем. 

Я бы начал с функционала и требований к нему. Кто-то думает над сценариями. Из них вытекают роли и всё, что с ними связано. 

Если заказчик понимает, что он хочет получить в итоге - проблемы не будет. Или это можно сделать, или нет. А дальше всё идёт в соответствии с жизненным циклом системы.

Логика подходящая, особенно если добавить задачи создания удобств для пользователей для повышения производительности.

При этом производительность это как пользователям меньшими усилиями делать быстрее или больше работ!

Каких именно работ?

Просто так или по наитию в корпоративной системе никто никаких работ не делает. Для всего нужны права доступа и функционал в соответствии с поддерживаемым системой процессом и сценарием для этого рабочего места.

Корпоративные системы категории ERP с несколькими функциональными модулями (иногда 10+) и соответствующими структурами данных, к примеру, могут поддерживать эффективное решение сотен различных задач одновременно для тысяч и десятков тысяч пользователей. Таких примеров достаточно.

Быстрее или больше - не критерий. Важно правильно и в срок. Без повторов, петель, лишних циклов, исправлений и переделок. Деньги обычно теряются именно на этом.

Почему, собственно, не очень понятно, о чём на самом деле написана статья.

Евгений, Вы удивляете вопросом о том какие работы могут быть в корпорации, а затем отражаться в ПО.

Я говорю о функционале конкретной системы, которую спроектировали на основе вполне определённого набора требований. Обычно они собираются снизу вверх и сверху вниз, отражают планы компании, функционал и мнения сотрудников, обрабатываются, анализируются, обсуждаются и передаются для исполнения разработчикам.

Что Вас здесь удивляет?

С учетом того что происходит на самом деле для того чтобы выполнять намеченные планы как раз и нужны "быстрее и больше"!

Это совершенно не обязательно. Больше чего? Быстрее чего? И как это связано с конкретной системой?

Для выполнения каких угодно планов нужны вполне определённые действия. А любая система, если она не 100% автоматическая - только инструмент достижения этих планов, которым пользуются по мере необходимости. И его возможности нужно знать и уметь  ими правильно пользоваться.

Или Вы знаете такие компании где все и всегда идет так как было намечено первоначальным планом?

В большмх компаниях планов обычно много, на разных уровнях и в нескольких редакциях. Готовятся и меняются по мере необходимости. Корпоративные системы существенно упрощают эту работу.

Вряд ли кто-то работает без плана, хотя возможно и такое.

Я правда принимаю также во внимание что платежеспособных заказов может быть больше и планы могут изменяться в связи с изменением рыночного спроса!

Замечательно. Ну и что? Планы меняются, прогнозы меняются. Все об этом знают.

В Вашей концепции планы должны быть низкими чтобы точно исполнимыми или возможны увеличения?

У меня нет для Вас никаких специальных концепций. То, что выше - отраслевая практика, ей десятки лет. Общее знание.

Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Одной из проблем ERP является то что она создается под рабочие места топ-менеджеров, под их удобства!

На сколько эти удобства создают удобства или неудобства для других рабочих мест - вероятно об этом и другом статья Марии.

Коротко отвечу, Борис: нет, это не так. Каждое рабочее место определенной роли разрабатывается индивидуально в зависимости от роли в системе. Именно для этого проводится обследование.

И обучение производится. И сущестует 1 линия поддержки. 

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

А я вот с Борисом согласен. При внедрении ЕRP все плюшки (ну почти) уходят менеджменту.  И это как раз очень понятно. Так как запрос на ERP формируется из потребности в прозрачности, безопасности, единой правде из одного глобального источника, избавлении от разрозненного софта, снижении (типа) операционных затрат и пр. Т.е. это не запрос простого работника.  Его (простого работника) жизнь при этом становится куда сложнее. За ту же при этом зарплату. То, что раньше делалось в два приема, теперь делается в пять приемов. Там где раньше один сотрудник мог сделать что-то быстро в одиночку, теперь спотыкается о сегрегацию ответственности, которую в ERP (нормальной) не обойти. И так далее.  Массовый исход сотрудников после внедрения новых систем не редкость. Риск для менеджмента тоже высок. Теперь ты сильно зависишь от узкоспециализированной квалификации персонала, без которого ERP работать не будет. И я не про поддержку. Поддержка - это само собой. Я про персонал, который собственно и работает в ERP.  Ушел сотрудник внезапно - процесс встал. Быстро не найти, а найдешь - нужно потратить время на обучение. А работа при этом не ждет.  Я был свидетелем дорогостоящих внедрений, которые поработав какое-то время сходили на нет. Из-за того, что люди разбегались. А новых вовремя нанять и обучить не получается. И опять откат к экселу, разрозненному софту и объединению функционалов невзирая на сегрегацию ответственности и прочие требования. ERP как правило нормально работают в крупных структурах с избытком персонала, когда, образно, одно бревно несут 10 человек. Когда в обычных условиях хватило бы и четырех.  

Короче, ERP не для всех.

Сергей Попов пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Главный вопрос в том, что представитель заказчика может не иметь компетенций или полномочий по улучшению труда пользователей на разных рабочих местах. Он заказывает ПО для компании! 

Как правило рабочие места делятся по ролям пользователя. Роли прописываются в ТЗ. Это если мы ставим автоматизированную систему. В хороших системах и роли могут настраиваться и добавляться.

Типичные роли: руководитель, админ, пользователь. Но это далеко не конечный список.

Совсем не вижу здесь проблем. 

Я бы начал с функционала и требований к нему. Кто-то думает над сценариями. Из них вытекают роли и всё, что с ними связано. 

Если заказчик понимает, что он хочет получить в итоге - проблемы не будет. Или это можно сделать, или нет. А дальше всё идёт в соответствии с жизненным циклом системы.

интересная статья, но к сожалению, у меня нет опыта внедрения или эксплуатации ЕРП. Но начало обсуждения, и вот этот Ваш пост постоянно возвращали меня к мысли именно о "Функционале". На кой чёрт нам нужен этот дорогущий продукт?! Какие вопросы он поможет нам решить? Эти вопросы стоят тех денег, которые с нас слупят в результате установки и пожизненного сопровождения? Чаще всего, мы даже не представляем себе, во что ввязываемся. "Мы" - тут я и себя вплёл )) Всё же, мы меняли Автоматизированную банковскую систему. Одну на другую, да ещё на платформе Оракл. Консультанты и внутренние лоббисты говорили, что "всё будетлетать!". Я до сих пор не могу понять, ЧТО должно было лететь и куда. Да, какие-то бизнес - операции стали проводить, но потом приходилось каждый новый модуль или внесение изменений из-за изменившегося законодательства покупать снова. Вся банковская система России сидела на нескольких разработчиках, как на игле. И сейчас сидят...

Да, про функционал... :)) Читаю и думаю, как мне купить телефон без всех этих наворотов и обязательных приложений? Я не знаю, может быть, кто-то использует хотя бы половину всех возможностей телефона? ЭТо половвина функций не нужна? Она же оплачена?

Да, я и в машине не все функции выучил :)) 

Что там люди от ЕРП недополучают? Главную книгу ведёт - и Ладно!)))

Вы затронули очень горячую точку. Это действительно так. Навязывание функционала это фишка маркетологов. Я называю это синдромом Билла Гейтса: предложить излишний, как правило недоработанный функционал, чтоб потом брать деньги на дальнейшее развитие. Частично разработчики правы: почти невозможно автоматизировать одно направление, не касаясь другое. Бухгалерия тянет налоги, кадры, соцфонды, переработки, учет рабочеог времени и т.д.

Но ведь это не вина разработчика, а мечты закзачика. Не зря они смущали вас термином "Будет летать". И автомобиль мы берём и радуемся круиз-контролю, хотя он нафиг не нужен. 

Частично каждый заказа для разработчика является тестовым.  

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

Много ли функций мы используем в ворде?

Евгений Равич пишет:
Если на торте 25 розочек, придётся заплатить. 

Браво, Евгений!

Вадим Ильчук пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Одной из проблем ERP является то что она создается под рабочие места топ-менеджеров, под их удобства!

На сколько эти удобства создают удобства или неудобства для других рабочих мест - вероятно об этом и другом статья Марии.

Коротко отвечу, Борис: нет, это не так. Каждое рабочее место определенной роли разрабатывается индивидуально в зависимости от роли в системе. Именно для этого проводится обследование.

И обучение производится. И сущестует 1 линия поддержки. 

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

А я вот с Борисом согласен. При внедрении ЕRP все плюшки (ну почти) уходят менеджменту.  И это как раз очень понятно. Так как запрос на ERP формируется из потребности в прозрачности, безопасности, единой правде из одного глобального источника, избавлении от разрозненного софта, снижении (типа) операционных затрат и пр. Т.е. это не запрос простого работника.  Его (простого работника) жизнь при этом становится куда сложнее. За ту же при этом зарплату. То, что раньше делалось в два приема, теперь делается в пять приемов. Там где раньше один сотрудник мог сделать что-то быстро в одиночку, теперь спотыкается о сегрегацию ответственности, которую в ERP (нормальной) не обойти. И так далее.  Массовый исход сотрудников после внедрения новых систем не редкость. Риск для менеджмента тоже высок. Теперь ты сильно зависишь от узкоспециализированной квалификации персонала, без которого ERP работать не будет. И я не про поддержку. Поддержка - это само собой. Я про персонал, который собственно и работает в ERP.  Ушел сотрудник внезапно - процесс встал. Быстро не найти, а найдешь - нужно потратить время на обучение. А работа при этом не ждет.  Я был свидетелем дорогостоящих внедрений, которые поработав какое-то время сходили на нет. Из-за того, что люди разбегались. А новых вовремя нанять и обучить не получается. И опять откат к экселу, разрозненному софту и объединению функционалов невзирая на сегрегацию ответственности и прочие требования. ERP как правило нормально работают в крупных структурах с избытком персонала, когда, образно, одно бревно несут 10 человек. Когда в обычных условиях хватило бы и четырех.  

Короче, ERP не для всех.

Безусловно так, ERP не для всех. Штучка дорогая, штучка предполагает, что бизнес-процессы имеют устойчивое развитие. ERP не нужна бригаде плотников. Не нужна там, где все очевидно и ресурсы могут легко учитываться "на бумажке".

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

Да, вы правы, любая АС требует повышение компетентности пользователей. Если хорошего жокея посадить на Мерседес, он не будет хорошим водителем.

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

И кстати, что сложного в подобном оформлении накладных и какую плюшку у него в этом случае отнимает менеджмент? Тем более, что половину дела делает штрих-код.

Евгений Равич пишет:
Борис Кондрабаев пишет:
Евгений Равич пишет:
Борис Кондрабаев пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Главный вопрос в том, что представитель заказчика может не иметь компетенций или полномочий по улучшению труда пользователей на разных рабочих местах. Он заказывает ПО для компании! 

Как правило рабочие места делятся по ролям пользователя. Роли прописываются в ТЗ. Это если мы ставим автоматизированную систему. В хороших системах и роли могут настраиваться и добавляться.

Типичные роли: руководитель, админ, пользователь. Но это далеко не конечный список.

Совсем не вижу здесь проблем. 

Я бы начал с функционала и требований к нему. Кто-то думает над сценариями. Из них вытекают роли и всё, что с ними связано. 

Если заказчик понимает, что он хочет получить в итоге - проблемы не будет. Или это можно сделать, или нет. А дальше всё идёт в соответствии с жизненным циклом системы.

Логика подходящая, особенно если добавить задачи создания удобств для пользователей для повышения производительности.

При этом производительность это как пользователям меньшими усилиями делать быстрее или больше работ!

Каких именно работ?

Просто так или по наитию в корпоративной системе никто никаких работ не делает. Для всего нужны права доступа и функционал в соответствии с поддерживаемым системой процессом и сценарием для этого рабочего места.

Корпоративные системы категории ERP с несколькими функциональными модулями (иногда 10+) и соответствующими структурами данных, к примеру, могут поддерживать эффективное решение сотен различных задач одновременно для тысяч и десятков тысяч пользователей. Таких примеров достаточно.

Быстрее или больше - не критерий. Важно правильно и в срок. Без повторов, петель, лишних циклов, исправлений и переделок. Деньги обычно теряются именно на этом.

Почему, собственно, не очень понятно, о чём на самом деле написана статья.

Евгений, Вы удивляете вопросом о том какие работы могут быть в корпорации, а затем отражаться в ПО.

Я говорю о функционале конкретной системы, которую спроектировали на основе вполне определённого набора требований. Обычно они собираются снизу вверх и сверху вниз, отражают планы компании, функционал и мнения сотрудников, обрабатываются, анализируются, обсуждаются и передаются для исполнения разработчикам.

Что Вас здесь удивляет?

С учетом того что происходит на самом деле для того чтобы выполнять намеченные планы как раз и нужны "быстрее и больше"!

Это совершенно не обязательно. Больше чего? Быстрее чего? И как это связано с конкретной системой?

Для выполнения каких угодно планов нужны вполне определённые действия. А любая система, если она не 100% автоматическая - только инструмент достижения этих планов, которым пользуются по мере необходимости. И его возможности нужно знать и уметь  ими правильно пользоваться.

Или Вы знаете такие компании где все и всегда идет так как было намечено первоначальным планом?

В большмх компаниях планов обычно много, на разных уровнях и в нескольких редакциях. Готовятся и меняются по мере необходимости. Корпоративные системы существенно упрощают эту работу.

Вряд ли кто-то работает без плана, хотя возможно и такое.

Я правда принимаю также во внимание что платежеспособных заказов может быть больше и планы могут изменяться в связи с изменением рыночного спроса!

Замечательно. Ну и что? Планы меняются, прогнозы меняются. Все об этом знают.

В Вашей концепции планы должны быть низкими чтобы точно исполнимыми или возможны увеличения?

У меня нет для Вас никаких специальных концепций. То, что выше - отраслевая практика, ей десятки лет. Общее знание.

Меня удивило то, что Вы попросили привести перечень работ, в моем понимании всех что существуют в корпорации?!

Еще более удивило, что для выполнения работ "точно и в срок" не нужно периодическое использование "быстрее и больше"?!

Меня удивляет что Вы чаще всего говорите правильные вещи и порой задаете странные вопросы.

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

Это примерно то о чем Вам сказала Ирина, в дискуссии о доверии.

Попробую пояснить другими словами про "быстрее и больше".

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

Для того чтобы вновь войти в плановые графики нужно уметь на разных рабочих местах делать "быстрее и больше"!

Вероятно, что нервничать меня заставляет пока до конца не понятая мной роль АСУ или ERP в том, что если нужно изменить на каком то рабочем месте режим до "быстрее и больше", то традиционная автоматизация позволяет это сделать или запрещает?

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

Это также можно отнести и к проблеме повышения производительности компаний. АСУ нам друг или враг?

Анатолий Курочкин пишет:
Вадим Ильчук пишет:
Анатолий Курочкин пишет:
Борис Кондрабаев пишет:
Одной из проблем ERP является то что она создается под рабочие места топ-менеджеров, под их удобства!

На сколько эти удобства создают удобства или неудобства для других рабочих мест - вероятно об этом и другом статья Марии.

Коротко отвечу, Борис: нет, это не так. Каждое рабочее место определенной роли разрабатывается индивидуально в зависимости от роли в системе. Именно для этого проводится обследование.

И обучение производится. И сущестует 1 линия поддержки. 

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

А я вот с Борисом согласен. При внедрении ЕRP все плюшки (ну почти) уходят менеджменту.  И это как раз очень понятно. Так как запрос на ERP формируется из потребности в прозрачности, безопасности, единой правде из одного глобального источника, избавлении от разрозненного софта, снижении (типа) операционных затрат и пр. Т.е. это не запрос простого работника.  Его (простого работника) жизнь при этом становится куда сложнее. За ту же при этом зарплату. То, что раньше делалось в два приема, теперь делается в пять приемов. Там где раньше один сотрудник мог сделать что-то быстро в одиночку, теперь спотыкается о сегрегацию ответственности, которую в ERP (нормальной) не обойти. И так далее.  Массовый исход сотрудников после внедрения новых систем не редкость. Риск для менеджмента тоже высок. Теперь ты сильно зависишь от узкоспециализированной квалификации персонала, без которого ERP работать не будет. И я не про поддержку. Поддержка - это само собой. Я про персонал, который собственно и работает в ERP.  Ушел сотрудник внезапно - процесс встал. Быстро не найти, а найдешь - нужно потратить время на обучение. А работа при этом не ждет.  Я был свидетелем дорогостоящих внедрений, которые поработав какое-то время сходили на нет. Из-за того, что люди разбегались. А новых вовремя нанять и обучить не получается. И опять откат к экселу, разрозненному софту и объединению функционалов невзирая на сегрегацию ответственности и прочие требования. ERP как правило нормально работают в крупных структурах с избытком персонала, когда, образно, одно бревно несут 10 человек. Когда в обычных условиях хватило бы и четырех.  

Короче, ERP не для всех.

Безусловно так, ERP не для всех. Штучка дорогая, штучка предполагает, что бизнес-процессы имеют устойчивое развитие. ERP не нужна бригаде плотников. Не нужна там, где все очевидно и ресурсы могут легко учитываться "на бумажке".

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

Да, вы правы, любая АС требует повышение компетентности пользователей. Если хорошего жокея посадить на Мерседес, он не будет хорошим водителем.

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

И кстати, что сложного в подобном оформлении накладных и какую плюшку у него в этом случае отнимает менеджмент? Тем более, что половину дела делает штрих-код.

Анатолий, Вы верно меня поняли!

Про датчики я тоже знал, плюс создание таких датчиков обозначено официально в приоритете финансирования ЦТИ.

Я еще делаю упор на автономизацию можно сказать в разрезе ИИ, то есть изучения самых успешных и компетентных специалистов с целью унификации использования их опыта, а не только правил и требований каких то инструкций!

Для создания талантливых сотрудников нужны два компонента - знать теорию и уметь это делать на практике!

Так же и при обучении ИИ, АСУ или ERP нужно и то и другое.

Так как практикует все же не ИИ, а человек, за исключением робота, то ИИ может помогать человеку, напоминая чек-листом о том какие действия и в какой момент нужно совершить.

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

 

Борис Кондрабаев пишет:
Анатолий Курочкин пишет:

Безусловно так, ERP не для всех. Штучка дорогая, штучка предполагает, что бизнес-процессы имеют устойчивое развитие. ERP не нужна бригаде плотников. Не нужна там, где все очевидно и ресурсы могут легко учитываться "на бумажке".

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

Да, вы правы, любая АС требует повышение компетентности пользователей. Если хорошего жокея посадить на Мерседес, он не будет хорошим водителем.

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

И кстати, что сложного в подобном оформлении накладных и какую плюшку у него в этом случае отнимает менеджмент? Тем более, что половину дела делает штрих-код.

Анатолий, Вы верно меня поняли!

Про датчики я тоже знал, плюс создание таких датчиков обозначено официально в приоритете финансирования ЦТИ.

Я еще делаю упор на автономизацию можно сказать в разрезе ИИ, то есть изучения самых успешных и компетентных специалистов с целью унификации использования их опыта, а не только правил и требований каких то инструкций!

Для создания талантливых сотрудников нужны два компонента - знать теорию и уметь это делать на практике!

Так же и при обучении ИИ, АСУ или ERP нужно и то и другое.

Так как практикует все же не ИИ, а человек, за исключением робота, то ИИ может помогать человеку, напоминая чек-листом о том какие действия и в какой момент нужно совершить.

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

 

Благодарю,Борис!

Идея ваша понятна и не лишена смысла, особенно в разрезе ИИ.
Но ведь роль обычного оператора не отличается каким-то супер-пупер предназначением.

Он или заводит новый документ, или правит его, или удаляет. Все.

Накладные, акты, сверки. Пользователь с чуть более высокой ролью может, например, вносить график ППР. ERP  в грубом представлении является той же учетной системой. Какое может быть творчество у оператора склада? Какой необыкновенный опыт нужно автоматизировать?
Да, часто к ней подключаются системы геопозиционирования, которые вычисляют оптимальные маршруты транспорта. 
Система может предложить варианты оптимизации загрузки склада. Друие аналогичные функции. 

1 3 5 7 11
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Половина россиян верит в финансовые приметы

Наиболее распространенными оказались приметы, связанные с обращением с деньгами.

5 профессий с самым высоким риском выгорания

Список возглавили – HR-специалисты.