Классы отраслевых решений ERP

Изложенный в статье подход к проблеме не понравился.
Теоретически всё.
Вводится несколько искусственных классификаций решений и ничего больше.

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

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

[Мартынов Дмитрий]

Цитата:

Сообщение от erp_man

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

А по каким критериям вы бы выбирали отраслевое решение ?

Цитата:

Сообщение от erp_man

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

Я много раз сталкивался с тем, что как раз анализ функционала - это, как вы говорите, чисто теоретическая искусственная конструкция. Реальное же понимание его содержания приходит только в процессе внедрения и именно тогда выясняется, что функции не достаточно содержательны или вообще не жизнеспособны. С этим так же связана очевидная проблема со сравнением функционала двух систем. Это сделать не возможно, т.е. возможно, но результат будет демагогией и не более того... В статье "Проблемы быстродействия ERP - системный кризис" я описывал это так:

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

Если функционал сравнивать бессмысленно, то как выбрать отраслевое решение ? Этот вопрос и сподвиг меня к поиску альтернативных признаков выбора отраслевого решения, и они описаны в статье "Классификация отраслевых решений".

Может быть я чего то не догоняю ? Можете дать ссылку на то, как правильно сравнивать две системы по функционалу ? Ну или сами предложите качественный подход ?

[Мартынов Дмитрий]

Цитата:

Сообщение от erp_man

Теоретически всё.
Вводится несколько искусственных классификаций решений и ничего больше.

Вы намекаете на то, что у меня нет опыта?
В статьях была попытка аккумулировать опыт нескольких специалистов, но все равно, статья основана в большей мере на собственном опыте. Он не бесконечен – это порядка двух проектов каждый год (на различных программных платформах), начиная с 98 года, но зато все стадии от начала (переговоров) и до конца (эксплуатации)…

Цитата:

Сообщение от erp_man

Это банально, но работает на практике.
Как это делал для крупных проектов:

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

Цитата:

Сообщение от erp_man

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

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

Цитата:

Сообщение от erp_man

Проводим "допрос" поставщиков.
они должны выполнить gap анализ (анализ карты покрытия функционала) и набросать картинку того, как будут реализованы заказанные нами процессы.

Я принципиальный противник функционального сравнения систем – это: трудоемкость + необъективность.

Цитата:

Сообщение от erp_man

но... попробуйте посчитать вероятность невыполнения поставщиком своих обязательств на основании предложенной классификации?

Способ, о котором говорю я в статье плох тем, например, что дает мало информации о том, какие функции придется дописывать. Но по этому показателю он так же плох как гэп анализ (слишком уж часто те кто его делают получают результаты, которые в ходе проекта не подтверждаются). Таким образом предлагаемый в статье «Классификация отраслевых решений» способ анализа – хоть и плох, НО он лучше всего, что сейчас есть: он объективен (мы говорим про вещи, можно проверить и оценить) и прост (низкие трудозатраты).

Цитата:

Сообщение от erp_man

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

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

Надо двигаться в перед, а то ведь так и будем прижигать раны и бояться приведений с мотором…

P.S.
Маккинси я не читал, дайте плиз ссылку? Порекомендуйте что то конкретное?