Русский вопрос - разборки по понятиям на рынке ERP (Предпроект)

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

Попробую подвести итог опроса по наличию неформальных правил рынка ERP.
Это итог двух дискуссий (вторая здесь)

Было высказано какое то количество мнений и среди них я бы выделил две идеи, которые эти мнения объединяют. У каждой идеи, есть свои изъяны, которые тоже были обозначены в беседе.

1. Все важные решения должен принимать Заказчик (видимо эта мысль исходила из уст тех кто относит себя к Интеграторам).
а) Первый изъян: Интегратор вряд ли готов высказывать эту мысль Заказчику раньше чем получит аванс.
б) Ценностью являются навыки эксперта по принятию решений и выбору оптимального пути. Заказчик видит в Интеграторе эксперта.
в) Третий изъян: Заказчик не знает возможностей и особенностей ПО, а важные решения могут касаться и этого вопроса.

2. Вторая идея в том, что надо постоянно следить за тем что делает Интегратор, явно исходила от представителей Заказчика.
а) Изъян здесь в том, что идея держится на иллюзии, что Интегратор вообще будет что то делать, в то время, как из п.1. вытекает, то, что Интегратор ни чего делать не собирается.
Видимо именно по этому в гипертрофированном виде идея прозвучала так: мы уже боимся, что либо доверять Интегратору, мы только купим у него лицензии.
б) Нанимать свою команду экспертов, а это вопрос хлопотный и не менее рискованный чем, бодание с Интегратором.

Изъяны обоих идей создают неприятности скорее Заказчику, чем Интегратору, по этому сделаю смелый вывод – результат обсуждаемого проекта по SAP вполне закономерен и платформонезависим

[mazzy]

Цитата:

Сообщение от Мартынов Дмитрий

1. Все важные решения должен принимать Заказчик

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

Квантор всеобщности "Все" и квалификатор "важные" в одном утверждении делают это утверждение бессмысленным.

А модальность долженствования "должен" делает ситуацию патовой (загоняет ситуацию в тупик).

Цитата:

Сообщение от Мартынов Дмитрий

2. Вторая идея в том, что надо постоянно следить за тем что делает Интегратор

Дим, я тебе с самого начала говорил, что тебе нужно разобраться с модальностями. У тебя постоянно путается "должен", "имеет право", "надо"...

Кому "надо"? Кто будет выполнять это "надо"?

Я бы сформулировал ожидаемые границы взаимодействия в проектах так:

1. Ответственность за результат - совокупная
2. Заказчик имеет право принять любое решение (в том числе и неправильное, в том числе "отсутствие решения") по любому вопросу любого уровня важности и/или сложности.
   • В том числе, заказчик имеет право возложить решения по любым (по всем или выборочно) вопросам на Исполнителя. При этом, ответственность за результат остается совокупной.
3. Исполнитель имеет право давать рекомендации Заказчику по любым вопросам проекта. При этом, Заказчик имеет право эти рекомендации не принимать (см. п.2)
4. Заказчик имеет право получить от Исполнителя разъяснений по любым аспектам и вопросам проекта. При этом, Исполнитель имеет право ответить "отпиской"
5. Исполнитель имеет право потребовать решения Заказчика по любым вопросам проекта. При этом, Заказчик имеет право ответить "отпиской" или "отсутствием решения".
6. Заказчик имеет право отказаться от работы с Исполнителем (как до, так и после заключения заключения договора). При этом, все принятые (закрытые актами) работы все равно должны быть оплачены Заказчиком И предусмотренные для такого исхода заключенным договором штрафы - выплачены Заказчиком.
7. Исполнитель имеет право отказаться от работы с Заказчиком (как до, так и после заключения заключения договора). При этом, все авансы за не принятые (не закрытые актами) работы должны быть возвращены Исполнителем И предусмотренные для такого исхода заключенным договором штрафы - выплачены Исполнителем.
8. Cтороны имеют право не выполнять условия, не указанные в заключенном договоре
   • При этом, Стороны имеют право указать в договоре процедуру изменения заключенного договора (один из вариантов - запрет изменения). Измененный договор, прошедеший согласованную процедуру изменения, становится "заключенным договором"
9. При любой форме договора, Стороны имеют право на судебную, уголовную и любую иную защиту, которое предоставляет государство.
   • В том числе, Стороны имеют право на приоритет законодательства перед формально заключенным договором.

Обратите внимание, что пунктами 4 и 5 стороны обычно не злоупотребляют при нормальных долгосрочных отношениях. Но право имеют!

И обратите внимание, что договоры между Закзачиком и Исполнителем так или иначе ограничивают права, которые идут после слов "при этом". Насколько жестким будет эти ограничения в заключенном договоре, настолько жестким будет проект.

Другими словами:
= Заказчик может принимать любое решение по любым вопросам, в том числе и вопреки рекомендациям Исполнителя
= Заказчик и Исполнитель могут общаться друг с другом по вопросам проекта
= Если у них не получается конструктивного общения, то любой может "соскочить" с договора, при этом вернув деньги по (не)заактированным работам и, если это предусмотрено договором, уплатив штраф
= Формально заключенный договор не может противоречить законодательству. Неформальный договор - может противоречить, но Уголовный кодекс имеет приоритет перед любыми договоренностями.

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

[Bobkov]

Цитата:

Сообщение от Мартынов Дмитрий

1. ну да - степень свободы... Но его же нет - понимания этого - где ж его взять?
...

Старая песня о главном...
Мы постарались описать проблему и дать ответ на этот вопрос в данной статье:
http://www.e-xecutive.ru/knowledge/a...ement/1141796/

Цитата:

Сообщение от Мартынов Дмитрий

У каждой идеи, есть свои изъяны, которые тоже были обозначены в беседе.

1. Все важные решения должен принимать Заказчик (видимо эта мысль исходила из уст тех кто относит себя к Интеграторам).
а) Первый изъян: Интегратор вряд ли готов высказывать эту мысль Заказчику раньше чем получит аванс.
б) Ценностью являются навыки эксперта по принятию решений и выбору оптимального пути. Заказчик видит в Интеграторе эксперта.
в) Третий изъян: Заказчик не знает возможностей и особенностей ПО, а важные решения могут касаться и этого вопроса.

2. Вторая идея в том, что надо постоянно следить за тем что делает Интегратор, явно исходила от представителей Заказчика.
а) Изъян здесь в том, что идея держится на иллюзии, что Интегратор вообще будет что то делать, в то время, как из п.1. вытекает, то, что Интегратор ни чего делать не собирается.
Видимо именно по этому в гипертрофированном виде идея прозвучала так: мы уже боимся, что либо доверять Интегратору, мы только купим у него лицензии.
б) Нанимать свою команду экспертов, а это вопрос хлопотный и не менее рискованный чем, бодание с Интегратором.

Изъяны обоих идей создают неприятности скорее Заказчику, чем Интегратору, по этому сделаю смелый вывод – результат обсуждаемого проекта по SAP вполне закономерен и платформонезависим

Не согласен с обеими идеями.
Главная проблема - недостаточное определение требований к результату проекта до его начала. Очень часто Заказчик отказывается достаточно точно определить их. Очень часто Исполнитель с этим согласен. И отправляются они в путь, не имея точного согласованного представления о том, куда они хотят попасть. Ждут их на этом пути страшные приключения...
Что делать? Определять требования к результату проекта до его начала! Для этого Заказчику необходимо выращивать собственные управленческие компетенции или приобретать их на рынке.

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

Цитата:

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

Старая песня о главном...
Мы постарались описать проблему и дать ответ на этот вопрос в данной статье:
http://www.e-xecutive.ru/knowledge/a...ement/1141796/

Предложенная Вами статья имеет весьма косвенное отношение к данной теме, по этому я прошу модераторов выделить ее обсуждение в отдельную ветку

Я кстати зарегистрировался на вашем форуме, но это не дало мне возможность оставить комментарий к статье (как то там у Вас все строго.... меня наверно еще долго буду проверять прежде чем мне начнут доверять )
В связи с этим прокомментирую статью здесь.

[Bobkov]

Цитата:

Сообщение от Мартынов Дмитрий

Предложенная Вами статья имеет весьма косвенное отношение к данной теме

Цитата:

Сообщение от Мартынов Дмитрий

В связи с этим предлагаю всем высказаться на тему о том по каким понятиям существует рынок ERP систем

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

Цитата:

Сообщение от Мартынов Дмитрий

Я кстати зарегистрировался на вашем форуме, но это не дало мне возможность оставить комментарий к статье (как то там у Вас все строго.... меня наверно еще долго буду проверять прежде чем мне начнут доверять )

Форум этот не наш, мы там такие же рядовые участники.

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

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

Не споря с парадигмой обращусь к инструментам. Я достаточно давно занимаюсь подрывом современной ERP науки (если ее можно назвать наукой). Судя по Вашей статье - не безуспешно (мои тезисы приживаются в массах...).

Однако, касаясь других аспектов, например управления предприятием, финансов, бюджетирования, управления проектами и заглядывая на более-менее серьезную глубину я вижу, что похожая ситуация не только в ERP но и в других науках. Эти методики изобилуют подлогами. Самые простые подлоги выглядят так "игнорируем сложные проблемы - решаем простые". Но есть много и более хитрых ловушек. Некоторые из них были вскрыты и озвучены сразу после обвала 2008. Другие остаются общепризнанными знаниями.

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

Положение спасает только то, что наши бизнесмены (я прежде всего про малый и средний бизнес), вникаю в детали и отсекают все непонятное и рискованное... И самостоятельно на ощупь ищут решения сложных проблем... Честь им и хвала!

[Bobkov]

Цитата:

Сообщение от Мартынов Дмитрий

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

Дмитрий, это ваше собственное ошибочное предположение В статье никаких "современных методик управления" не предлагается. Управлению по требованиям, предложенному в статье, лет тридцать как минимум. Там даже номер советского ГОСТа приведён.

Цитата:

Сообщение от Мартынов Дмитрий

Эти методики изобилуют подлогами. Самые простые подлоги выглядят так "игнорируем сложные проблемы - решаем простые". Но есть много и более хитрых ловушек.

В отношении "современных методик" зачастую так и есть, согласен.

Цитата:

Сообщение от Мартынов Дмитрий

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

Нужно всё-таки стараться фильтровать хаос не хаотично, а целенаправленно, методом "научного тыка". Альтернативы я не знаю. Таков уж у человека метод познания

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

Цитата:

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

Нужно всё-таки стараться фильтровать хаос не хаотично, а целенаправленно, методом "научного тыка".

Проверять применимость технологии на собственном предприятии "методом Монте-Карло" - это слишком жестко Но увы, вы правы - многие пытались (хорошо видно на примере тех же заваленных ERP проектов)

Цитата:

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

Альтернативы я не знаю. Таков уж у человека метод познания

Обращаю внимание -- есть более безопасные, и часто, вполне продуктивные научные методы.... Кстати, вы их знаете и даже применяете (из статьи это видно) ...

[Bobkov]

Цитата:

Сообщение от Мартынов Дмитрий

Обращаю внимание -- есть более безопасные, и часто, вполне продуктивные научные методы.... Кстати, вы их знаете и даже применяете (из статьи это видно) ...

Дмитрий, пожалуйста, напишите подробнее, какие именно более безопасные научные методы вы имеете в виду.

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

Цитата:

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

Дмитрий, пожалуйста, напишите подробнее, какие именно более безопасные научные методы вы имеете в виду.

Ну вы прям меня пугаете такими вопросами...
Читайте на Википедии.

Написано там путано, так что читайте все сверху донизу...