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

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

Эта тема навеяна двумя постами в ЖЖ (community.livejournal.com/ru_erp/110063.html, community.livejournal.com/ru_erp/110186.html), в которых рассказывалось о заваленном проекте и поднимались два истинно-русских вопроса - кто виноват и что делать. Обсуждение было бурное, кто то говорил, что виноват Исполнитель, кто то все валил на Заказчика.

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

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

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

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

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

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

[mazzy]

Цитата:

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

Предпроект
а) исполнитель ... должен ...?
б) [исполнитель] ... должен ...?
в) [исполнитель] ... имеет ли ... право ...?
г) заказчик ... должен ли ...?
д) заказчик ... имеет ли право ...?

Э-э-э... Дим, правильный вопрос - половина ответа.

А почему именно так выбраны модальности долженствования в вопросах?

"сапер имеет право ошибаться. но только один раз"

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

Цитата:

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

А почему именно так выбраны модальности долженствования в вопросах?

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

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

Цитата:

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

А почему именно так выбраны модальности долженствования в вопросах?

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

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

...Заказчик должен...

...она могла ...
...Могла....

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

сформулируй тему/вопрос в одной модальности.
и вопрос станет кристально ясным.

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

[Evgeniy2020]

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

1. Анализировать Проект договора между исполнителем и заказчиком.

2. Цели проекта и их достижение.

3. Коммуницирование и общее понимание целей и каких их достигнуть.

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

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

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

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

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


Заказчик должен сформулиовать, что он хочет получить.
Исполнитель должен изучить текущую ситуацию as is
и изучить, что необходимо получить to be.
заказчик и исполнитель должны прийти к общему понимаю
что будет получено в итоге и каким путем,
каковы преимущества и недостатки предложенного плана выполнения,

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

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

плохие начальные мероприятия могут привести к сюрпризу.
1. получили не то что хотели
2. не получили то что хотели к определенному сроку
3. не получили в рамках бюджета
4. заказчик изменил свое желание и это не отразилось в плане.
и т.д.

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

[mazzy]

Цитата:

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

Что касается формы вопросов - можно предложить другую?

Угу. "Мопед не мой. Я просто разместил объяву."

[Evgeniy2020]

По анализу информации уже вырисовываются возможные детали этого не внедерения:

1. «Стройдорэкспорт» объявил тендер на внедрение ERP-системы в октябре 2007 г., и по его результатам, рассмотрев решения на базе платформ Microsoft Dynamics AX, IFS Applications, «1С:Предприятие» и SAR ERP,

(выбрали SAP не Аксапту, и далее видно почему уже был возможный провал)

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

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

Эффективного времени 1,5 года. Обычный девиз при внедрении SAP
1 модуль 1 год. Следовательно при таком общем подходе за 1,5 года,
возможно эффективное внедрение 1,5 модуля. Например модуль финансов и пол модуля проектов. Задачка решена - землекопа полтора.

а тут еще одновременно во всех бизнес единицах холдинга. с учетом различий в этих бизнес единицах.

3. Стоимость проекта, по словам представителей заказчика, составила около 1 млн евро, и эти деньги поступили интегратору авансом.

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

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

Цитата:

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

По анализу информации уже вырисовываются возможные детали этого не внедерения:
1. «Стройдорэкспорт» объявил тендер.....

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

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

Цитата:

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

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

.

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

[pitersky]

Я бы сказал, что основные проблемы и тёрки между Исполнителем и Заказчиком возникают по причинам неявных пожеланий, на которых во время пресейла сознательно не заостряют внимание:
- Заказчик уверен, что Исполнитель за уплаченные деньги не только выполнит само внедрение (что подразумевает договор), но и бесплатно проведёт аудит и оптимизацию бизнес-процессов под угрозой непринятия этапов проекта;
- Исполнитель, зная об этом, специально ничего такого не оговаривает, дабы потом была легальная возможность в суде сказать "а мы всё сделали, что положено".
В результате каждая сторона уверена в своей правоте. И чисто формально обе правы. А по сути - обе НЕправы, и проект провален.

По-хорошему, любой переход на новую информационную платформу должен состоять из двух этапов:
1) Анализ, аудит и реконструкция бизнес-процессов;
2) Реализация БП в ИС

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

Т.е. я бы дал такие ответы:
а) Зависит от этапа. На этапе внедрения ИС задача от Заказчика должна быть максимально детальной.
б) Нет. Постановка задачи - всецело компетенция Заказчика
в) Нет. Если ставится задача прозрачности в реализации проекта, а не распила денег.
г) Нет. Исполнитель должен доказать Заказчику, что именно его надо выбрать. Затраты на презентацию - вполне законный и оправданный способ доказательства
д) Да. Желание выбрать самый дешёвый тариф при прочих равных вполне оправдано. Но только в силу п.а

[EVGL]

Скопирую сюда, а то не в ту тему изначально запостил

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

б) должен ли он это делать за свой счет?
-- нет. Вы представляете, сколько времени предпроект может занять? Времени, которое можно потратить, например, на активных клиентов, которые исправно платят.

в) имеет ли по понятиям Исполнитель право заключения отдельного тайного договора с представителем Заказчика (кто ни будь из представителей интеграторов возьмет на себя смелость это заявить) ?
-- нет

г) презентации – затраты Исполнителя, должен ли Заказчик их оплачивать (в случае если он выбрал этого Исполнителя и в случае если выбрал другого)?
-- первые презентации обычно никто не оплачивает. А если презентуем результат работы, то презентация - часть этой работы и потому оплачивается.

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

[ZornFire]

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

[Evgeniy2020]

а вообще тут все довольно просто.
есть Best practices.

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

отсюда исполнитель ДОЛЖЕН разработать клиентский код и поместить его на клиенте
серверный код должен быть на сервере

если вы пойдете наоборот провал обеспечен.
так же и в ведении проектов и договороной части.
есть внегласные Best practices.

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

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

поэтому задача сводится все степени свободы закрепить между заказчиком и исполнителем.

например

1. нет понимания что хотим получить. Первая степень свободы
2. нет контроля исполнения проекта. вторая степень свободы
3. нет контроля качества. третья степень свободы.
4. нет риск менеджмента. четвертая степень свободы.

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

http://n-t.ru/tp/mr/ph.htm

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

Цитата:

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

1. нет понимания что хотим получить. Первая степень свободы
2. нет контроля исполнения проекта. вторая степень свободы
3. нет контроля качества. третья степень свободы.
4. нет риск менеджмента. четвертая степень свободы.

1. ну да - степень свободы... Но его же нет - понимания этого - где ж его взять?
2. ну раз не знаем, что хотим получить, то непонятно, что надо контролировать...
3. как контролировать качество того о чем мы ни чего не знаем?
4. есть риск менеджмент, нет риск менеджмента - пиндык случился - все насмарку. Вот у нас был риск менеджмент во главе с Шайгу - но лес выгорел до тла...

Ладно на 2, 3 и 4 - это конечно издевательство. Но вопрос 1 вполне конкретен.

Цитата:

Сообщение от mr.ZF

По личному опыту знаю что за исполнителем нужен жёсткий контроль. А клиент уже должен заранее понимать что ему надо и заранее подготовиться к внедрению. В смысле зачем нанимать Исполнителя? Не родит же клиент себе сам ту же Аксапту о_О

Получается: Интегратор не нужен и возможно даже опасен, но Аксапту гдето купить надо... Естественно эта идея может быть рождена только умом Заказчика, которому надоели Интеграторы - сколько им не плати все равно ни за что не отвечают... Я правильно понял Вашу мысль?

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

Цитата:

Сообщение от mr.ZF

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

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

[ZornFire]

Цитата:

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

По личному опыту знаю что за исполнителем нужен жёсткий контроль. А клиент уже должен заранее понимать что ему надо и заранее подготовиться к внедрению. В смысле зачем нанимать Исполнителя? Не родит же клиент себе сам ту же Аксапту о_О

[ZornFire]

Цитата:

Получается: Интегратор не нужен и возможно даже опасен, но Аксапту гдето купить надо... Естественно эта идея может быть рождена только умом Заказчика, которому надоели Интеграторы - сколько им не плати все равно ни за что не отвечают... Я правильно понял Вашу мысль?

Нет. От чего же, не отвечают, отвечают, однако, контроль за исполнением критически необходим.

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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