Цитата:
Сообщение от
erp_man
Теоретически всё.
Вводится несколько искусственных классификаций решений и ничего больше.
Вы намекаете на то, что у меня нет опыта?
В статьях была попытка аккумулировать опыт нескольких специалистов, но все равно, статья основана в большей мере на собственном опыте. Он не бесконечен – это порядка двух проектов каждый год (на различных программных платформах), начиная с 98 года, но зато все стадии от начала (переговоров) и до конца (эксплуатации)…
Цитата:
Сообщение от
erp_man
Это банально, но работает на практике.
Как это делал для крупных проектов:
Вы приводите пример технологии, которая дает положительный результат, но это не является доказательством ее правильности. Раньше солдатам раны прижигали каленым железом и некоторые при этом выживали и на этом основании было принято считать это правильным способом лечения ран.
Цитата:
Сообщение от
erp_man
Следствием улучшения бизнес процессов является снижение фин резервов, остатков на складах, рисков в налоговых органах... и т д.
Есть еще факторы, которые кажутся нематериальными - новый отчет для руководства или скажем возможность директора видеть расход бюджета online.
ну экономия трудозатрат сотрудников еще....но обычно этот фактор выстреливает при первом переходе от наколенного учета.
далее число сотрудников может и не сокращаться, просто люди занимаются чем-то более интелектуальным.
и т д
Плюсы сильно зависят от того, как именно будут построены процессы или как они изменятся.
Дело в том, что полезность ERP состоит из огромного количества эффектов и сделать проект так, чтобы от него был только вред почти не возможно. Кстати, прекрасно работают проекты сделанные на коленке. Правильно ли это? Но если это работает не хуже, чем с использование gap-анализа, то стоит ли делать этот мутный и сомнительный анализ? Правильным образом сравнить системы не возможно даже теоретически. Например, восприятие внешнего интерфейса экспертами будет зависит от их личного жизненного опыта…
Цитата:
Сообщение от
erp_man
Проводим "допрос" поставщиков.
они должны выполнить gap анализ (анализ карты покрытия функционала) и набросать картинку того, как будут реализованы заказанные нами процессы.
Я принципиальный противник функционального сравнения систем – это: трудоемкость + необъективность.
Цитата:
Сообщение от
erp_man
но... попробуйте посчитать вероятность невыполнения поставщиком своих обязательств на основании предложенной классификации?
Способ, о котором говорю я в статье плох тем, например, что дает мало информации о том, какие функции придется дописывать. Но по этому показателю он так же плох как гэп анализ (слишком уж часто те кто его делают получают результаты, которые в ходе проекта не подтверждаются). Таким образом
предлагаемый в статье «Классификация отраслевых решений» способ анализа – хоть и плох, НО он лучше всего, что сейчас есть: он
объективен (мы говорим про вещи, можно проверить и оценить)
и прост (низкие трудозатраты).
Цитата:
Сообщение от
erp_man
На мой взгляд, к практике выбора решений - изложенный в статье подход отношения не имеет.
Хотелось бы услышать от вас более осмысленные претензии. Наличие полезного результат от других технологий не является доказательством их оптимальности. Нельзя исключать, что результат может быть и лучше. Неопробованность новой технологии не является доказательством ее неработоспособности…
Надо двигаться в перед, а то ведь так и будем прижигать раны и бояться приведений с мотором…
P.S.
Маккинси я не читал, дайте плиз ссылку? Порекомендуйте что то конкретное?