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

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

Обещал написать об отраслевых решениях и написал...

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

Через некоторое время пришел к выводу, что это слишком поверхностный взгляд на вещи и в итоге описал "Классы отраслевых решений". Здесь уже есть попытка сравнения разных и выявления лучших...

Думаю, что обе статьи имеют право на существование и пока ставлю точку на теоретической части этой темы...

[vaavr]

Автор справедливо употребил слово "теоретический" к изложенному материалу (последняя строчка). Практически заказчик не знает отличий горизонтальных решений от вертикальных и оперирует понятием "прототип", справедливо полагая, что путь от прототипа до целевого решения короче чем от стандартной системы. Если консалтер сможет продемонстрировать "живой" прототип и ответить на вопросы типа: "А что произойдет при смене версий", то шансы продажи резко возрастают.

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

Как это делал для крупных проектов

I. Расчет доходной части.
Фактически, я не покупаю систему.
За определенные деньги я покупаю для организации новые бизнес-процессы или их улучшение.

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

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

перед проектом рождаются "бизнес требования". Для серьезных проектов - размер документации по бизнес-требованиям может доходить до 1000 листов.
при составлении БТ принципиально не привязываемся к терминам одной системы.

до 2000 года были проблемы, т.к. управленцы часто не въезжали в основы логики СУБД, но сейчас "дремучих" стало мало.

II. Расходная часть

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

Далее, на стоимость работ по проекту накручивается остальное - лицензии, железо, поддержка и т д.


III. Расходная часть - 2. Риски.

Закладываем риски.
Самая сложная часть оценки.
Размер риска - еще можно посчитать, с вероятностью намного сложнее.

Вашу статью "Классы отраслевых решений" я бы отнес скорее к этой части.

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

IV прочее

оценка возможностей развития.
берем несколько вероятных проектов, из тех что сейчас не нужны, но через год - возможно. так как, например, мы купим новый бизнес или захотим выйти на IPO.
оцениваем вероятность и прибыль от их реализации на выбранной платформе, исходя из пп I-III.

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

Очень типичные рассуждения. Чисто списочный (редукционизский) подход. Я даже спорить не буду - вы мне уже на пол статьи тут наговорили ... Так что отвечу статьей чуть позже.

может подход и типичный, но только он работает. и не только в ИТ.
в отличие от некоторых нетипичных.

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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