Фамилии исполнителей в договоре между клиентом и внедренцем

[Ivanhoe]

Цитата:

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

Вопрос к специалистам: Как снижаются риски на проекте при использовании труда стажеров?

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

P.S. тут главное понимать кого и при каких условиях мы называем "стажером".

[Ivanhoe]

Цитата:

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

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

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

[raz]

Цитата:

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

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

согласен. только мой опыт показывает, что присылают стажеров ВМЕСТО консультантов (по ставке консультанта), т.е. клиент оплачивает обучение сотрудников консалтинговой компании.

[pm-erp]

Цитата:

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

Вопрос к специалистам: Как снижаются риски на проекте при использовании труда стажеров?

Один из методов: не допускать перераспределение (перекоса) бюджета проекта со стороны внедренца в сторону "бумажных" этапов (дизайн и т.п.).
Часто на сам запуск в ПЭ оставляют 5-10% от общего бюджета.
А потом, как правило, t&m.

[Lz_]

Цитата:

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

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

"Совершенно четко" относилось к набору функционала, т.е. рамкам проекта. А если знаем "совершенно четко" что нужно сделать, значит можно рассчитать сколько это будет стоить? Я не прав?

Если после ТЗ нельзя получить исчерпывающую информацию о том, что нужно сделать и что мы должны получить в итоге, то какую систему вы собираетесь сдавать? ТЗ - основной документ на систему. Всё остальное лишь уточняет ТЗ.

Цитата:

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

И очень мало клиентов (по своему опыту - исчезающе мало) готово отдельно платить за ТЗ и только потом получать оценку на остальной проект.

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

До ТЗ можно дать лишь оценочную стоимость, которая будет скорректирована после ТЗ. Точность оценки зависит от квалификации оценщика. Это аксиома .

В свою очередь могу сказать по своему опыту, что очень много, пугающе много IT компаний внедряют систему в 2 этапа: продажа "коробки" или лицензий и освоение часов на внедрение. Причем, в договоре никак не оговорено какой результат должны достигнуть. Предметом договора являются услуги, т.е. часы на внедрение: Разработчик их отработает, а клиент примет и оплатит Формально проект завершен удачно, лицензии проданы и оплачены, часы отработаны и оплачены. А копнуть глубже - .... В особенности, это характерно для небольших проектов. Вот на таких проектах и начинаются брачные танцы с фамилиями исполнителей.

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

Цитата:

Сообщение от pm-erp

Один из методов: не допускать перераспределение (перекоса) бюджета проекта со стороны внедренца в сторону "бумажных" этапов (дизайн и т.п.).
Часто на сам запуск в ПЭ оставляют 5-10% от общего бюджета.
А потом, как правило, t&m.

Запуск в ПЭ является практически формальностью, когда реально пройдены этапы опытной эксплуатации и приемочных испытаний. Практически это "подтягивание хвостов" в основном по документации, поэтому 5-10% вполне оправданы.

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

После запуска в ПЭ идет сопровождение, в больших системах это практически всегда t&m.

Цитата:

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

согласен. только мой опыт показывает, что присылают стажеров ВМЕСТО консультантов (по ставке консультанта), т.е. клиент оплачивает обучение сотрудников консалтинговой компании.

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

[dmitryul]

Lz_, смотря где. Бывает и такое, как Вы описали - осваиваются часы.

Но обычно все-таки на этапе обследования пишут четкое ТЗ и сроки работ и стоимость исходя из объемов и компетенции исполнителей (например, PM - 120 евро в час, ведущий консультант/программист - 80, старший консультант/программист - 60).

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

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

Да, "Точность оценки ТЗ зависит от квалификации оценщика." - золотые слова! А также от уровня его жадности, чтобы заполучить проект во что бы то ни стало.

[Lz_]

Цитата:

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

Lz_, смотря где. Бывает и такое, как Вы описали - осваиваются часы.

Но обычно все-таки на этапе обследования пишут четкое ТЗ и сроки работ и стоимость исходя из объемов и компетенции исполнителей (например, PM - 120 евро в час, ведущий консультант/программист - 80, старший консультант/программист - 60).

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

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

Вот иллюстрация моих слов о договоре на услуги. А вы мне говорите про "смотря где". Только при услугах по написанию ТЗ нужны компетенции исполнителей 120 евро/час и т.п.

Если договор на систему (fix), то сдается этап, например, ТЗ стоит 3 рубля. Срок исполнения 01.12.10. Все, клиента не особо волнует сколько будет задействовано ведущих по 120, ведомых по 30 и т.п. Это теперь должно волновать Разработчика, что бы ему (разработчику) уложиться в трудоемкость, а следовательно в стоимость этапа.

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

Цитата:

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

Да, "Точность оценки ТЗ зависит от квалификации оценщика." - золотые слова! А также от уровня его жадности, чтобы заполучить проект во что бы то ни стало.

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

[dmitryul]

Lz_, Вы что-то путаете.

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

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

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

Результатом обследования (анализа бизнес-процессов) является ТЗ на проектирование (или Дизайн проекта - кто как называет), где подробнейшим образом оговорены:
1.Объем работ (с точностью до поля в таблице, кнопки - одним словом, очень детально)
2. План-график работ с конкретными сроками сдачи этапов
3. Пресловутый список и компетенция исполнителей на проекте
4. Стоимость исходя из компетенции по каждому пункту (форма такая-то, потребуется ПМ x часов, консультант y часов, разработчик z часов, исходя из их ставок форма стоит xxx евро).

Если сроки неправильно рассчитали, заказчик за них не переплачивает - сумма остается фиксированной!

И еще, работал во многих крупных консалтинговых компаниях - где Вы видели почасовую оплату и освоенные часы, если это нормальный проект, а не под распил?

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

Если нет Дизайна - это возможно, но если оговорен четко объем работ и сроки, есть подписанный контракт на определенную сумму - какие тут часы?

[Lz_]

Цитата:

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

Lz_, Вы что-то путаете.

Нет, я ничего не путаю .

Скорее всего путаница возникает из-за не правильного использования терминологии. Термин Техническое задание (ТЗ) - это гостированный термин. Говоря проще, есть государственный стандарт, который определяет состав и содержание данного документа. Если документ соответсвует этим требованиям, то этот документ можно назвать ТЗ. Иначе, это что угодно, очень похоже, но это не ТЗ. Приводя аналогию это: Масло сливочное - ГОСТ XXXXXXX, Маслице сливочное - ТУ YYYYYYYY. Разницу чувствуете? Поробуйте - сразу почувствуете. Что написано в ГОСТе известно, что в ТУ - хз. Так именовать одинаковым названием продукты нельзя, а документы можно. От этого и вся путаница.

Цитата:

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

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

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

На данном этапе необходимо выбрать интегратора, который напишет ТЗ. В общем случае в ТЗ может и не упоминаться платформа на базе которой будет реализована система. Если разобраться с ТЗ, то в этом документе сформулированы основные требования, которые предъявляются к системе. По сути что должна и что не должна система уметь делать.

Цитата:

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

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

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

Цитата:

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

Результатом обследования (анализа бизнес-процессов) является ТЗ на проектирование (или Дизайн проекта - кто как называет),

Клиент не заказывал анализ бизнес-процессов, ему система нужна новая, а не анализы старой. Тем более, что новая система будет сделана по модели "как надо", а старая "как есть". Надеюсь, не нужно объяснять про несовпадение этих моделей и возможность трансформации и перераспределения функций пользователей в новой системе.

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

Цитата:

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

где подробнейшим образом оговорены:
1.Объем работ (с точностью до поля в таблице, кнопки - одним словом, очень детально)

ВОПРОС: Вы описываете только дополнительно создаваемые поля, кнопки формы или существующий функционал тоже описывается?

На этапе ТЗ п 1 технически не реализуем, т.е. не выполним. Как я уже писал, ТЗ может писаться на систему без привязки к платформе. В общем случае, система может быть реализована на нескольких платформах. Какие тогда таблицы, какие формы, о чем вы? П.1 это часть Технического или Рабочего проекта.

Цитата:

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

2. План-график работ с конкретными сроками сдачи этапов

Вот это правильно. Одобрям-с.

Цитата:

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

3. Пресловутый список и компетенция исполнителей на проекте
4. Стоимость исходя из компетенции по каждому пункту (форма такая-то, потребуется ПМ x часов, консультант y часов, разработчик z часов, исходя из их ставок форма стоит xxx евро).

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

ВОПРОС: Клиент говорит: Все ок меня все устраивает, но вот эта и эта, и вон та форма дорого, платить не буду. Что делаем?

ВОПРОС: Где документация по проекту? Где инструкции пользователей и конкретных рабочих мест? Когда появляется эксплуатационная документация?

Цитата:

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

Если сроки неправильно рассчитали, заказчик за них не переплачивает - сумма остается фиксированной!

Еще бы, а штраф за срыв сроков не хотите заплатить?

Цитата:

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

И еще, работал во многих крупных консалтинговых компаниях - где Вы видели почасовую оплату и освоенные часы, если это нормальный проект, а не под распил?

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

Если нет Дизайна - это возможно, но если оговорен четко объем работ и сроки, есть подписанный контракт на определенную сумму - какие тут часы?

Судя по вашему посту, вы весьма далеки от понимания того, когда, какие документы составляются по проекту и для чего они нужны. Это уровень ПМ, вам еще расти и расти до него.

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

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

Вот уж воистину, до проектов с фиксированной ценой нужно дорасти.

з.ы. Многа букаф, извините, больше не буду.

[kosenkov]

Цитата:

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

Нет, я ничего не путаю .

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

А в чем дилетантизм-то? Разные же могут быть условия оплаты по договору. В том числе и включающие предоплату

[ice]

Цитата:

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

А в чем дилетантизм-то? Разные же могут быть условия оплаты по договору. В том числе и включающие предоплату

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

[lev]

Попробую вставить свои пять копеек.
ИМХО.
Изначально проблема провала основной массы проектов гораздо глубже чем кажется. И кроется она не в проектной документации.
Есть одна особенность ведения бизнеса в России. И особенность эта печальна
У основной массы предприятий отсутствует бизнес-стратегия.
Т.е. компания не очень представляет куда она идет, чего хочет добиться, какие цели хочет достичь и какие задачи она должна выполнить для достижения своих целей! Просто плывет по течению.
И как следствие в ИТ так же отсутствует стратегия, и они просто выполняют техническое сопровождение компании, не более того.
И вот когда руководителю бизнеса хочется внедрить у себя какую нибудь программу (просто поиграться; для солидности; для повышения стоимости или ещё чего нибудь, но не для повышения эффективности бизнеса), он дает команду ИТ: "Внедряйте". А для чего это нужно, какие задачи должна выполнять системы, какие сектора она должна автоматизировать, бизнес просто не задумывается. И начинается творческий процесс внедрения системы.

В таких условиях, как мне кажется, даже идеально составленная проектная документация, не поможет. Не зная целей и задач, которые стоят перед бизнесом, не получится провести адекватного внедрения. Потому, что, у руководителей бизнес подразделений будут постоянно появляться новые идеи, старые идеи буду изменяться или вообще "удаляться", а вместо них появляться другие. В таком хаосе, адекватного проекта быть не может.

[dmitryul]

Lz_, по Вашим ответам я понял, в чем дело.

Я говорю про внедрение в коммерческих структурах, вы об внедрении в госсекторе.

Да, был пример - заказчик не указал предельный срок обследования. Сам и виноват - т.к. граничных сроков нет, подчиненные в первую очередь (а нафиг нас отвлекают!), внедренцы во-вторую (мы ходим-ходим, а всем некогда, отмахиваются, информацию из-под палки выбиваем) халявно относились к работе.

В нормальных компаниях пляшут от Дизайна проекта (там описываются все бизнес процессы, "хотелки" вплоть до конкретной кнопки и столбца с указанием конкретной стоимости за каждый элемент).

Что такое Технический, Рабочий проект? Если я правильно понимаю, это внутренняя документация интегратора, которая к заказчику не имеет ни малейшего отношения (он за них не платит).

Почитайте методологию Sure Step подробно - как я понял, Вы о ней не знаете.

Понятия не имею, как в госсекторе - как я понял из Ваших слов, там на этапе ТЗ распиливаются все деньги и до внедрения не доходит.

Да каких проектов с фиксированной ценой дорасти? А я что пишу - все проекты у нас с фиксированной ценой! Стоимость рассчитывается исходя из объема работ и неизменна!

Да, по поводу обследования - а Вы считаете, что заказчик должен платит по акту сдачи?

Ну да, а Вы сами обследование хоть раз проводили? Оно может тянуться от месяца (средние предприятия, до 100 человек) до года (1000 человек штата). И что, интегратору забесплатно этот год работать?

В договоре на обследование (анализ) указывается конкретно предельное количество часов, затраченных на обследование (например, по отделам) и его стоимость. В госструктурах обычно идет 60% предоплата на все проекты сразу, потом по закрытию этапов.

lev, не все так плохо. В средних коммерческих компаниях понимание, куда двигаться и что конкретно нужно переделать есть, поэтому переходят от лоскутной автоматизации (1С, самописки) к нормальным ERP системам. А об госструктурах и приближенных к ним я не говорю - это распил денег, цели повысить эффективность бизнеса никто не ставит.

[lev]

Цитата:

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

lev, не все так плохо. В средних коммерческих компаниях понимание, куда двигаться и что конкретно нужно переделать есть, поэтому переходят от лоскутной автоматизации (1С, самописки) к нормальным ERP системам. А об госструктурах и приближенных к ним я не говорю - это распил денег, цели повысить эффективность бизнеса никто не ставит.

хотелось бы в это верить
если это так, то мир бизнеса на правильном пути

З.Ы. Кстати я не про стратегию типа: "Мы завоюем мир, потому что мы самая крутая компания!", а про ту где описана цель и конкретные шаги (проекты ), которые необходимо сделать что бы её достичь

[pitersky]

Цитата:

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

Есть одна особенность ведения бизнеса в России. И особенность эта печальна
У основной массы предприятий отсутствует бизнес-стратегия.
Т.е. компания не очень представляет куда она идет, чего хочет добиться, какие цели хочет достичь и какие задачи она должна выполнить для достижения своих целей! Просто плывет по течению.

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

Кроме того, есть ещё одна проблема, о которой вы не упомянули. Это внутренние барьеры на предприятии. Высшее руководство может быть сколь угодно адекватным (или неадекватным), но если люди работают по принципу "то, что за дверью, меня не касается", то ни о какой единой бизнес-стратегии речь идти не может. Точнее, речь-то конечно может идти - вот только рядовые сотрудники это будут воспринимать как очередную блажь топов, которую надо выслушать, похлопать и забыть.

[lev]

Цитата:

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

...
Кроме того, есть ещё одна проблема, о которой вы не упомянули. Это внутренние барьеры на предприятии. Высшее руководство может быть сколь угодно адекватным (или неадекватным), но если люди работают по принципу "то, что за дверью, меня не касается", то ни о какой единой бизнес-стратегии речь идти не может. Точнее, речь-то конечно может идти - вот только рядовые сотрудники это будут воспринимать как очередную блажь топов, которую надо выслушать, похлопать и забыть.

согласен!

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

[Ivanhoe]

А про вину стажеров (топик) уже и забыли?

[Lz_]

Цитата:

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

А в чем дилетантизм-то? Разные же могут быть условия оплаты по договору. В том числе и включающие предоплату

Цитата:

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

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

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

Цитата:

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

В таких условиях, как мне кажется, даже идеально составленная проектная документация, не поможет. Не зная целей и задач, которые стоят перед бизнесом, не получится провести адекватного внедрения. Потому, что, у руководителей бизнес подразделений будут постоянно появляться новые идеи, старые идеи буду изменяться или вообще "удаляться", а вместо них появляться другие. В таком хаосе, адекватного проекта быть не может.

Согласен. Очень тяжело сделать качественную систему, если цели постоянно меняются.

Для минимизации этого риска пишется ТЗ . У него пункт 1 это Общие сведения, в которых указывается информация о заказчике, разработчике, шифры проекта, методология по которой происходит внедрение и другая общая информация. А вот вторым пунктом идут Назначение и цели создания. Вот здесь и необходимо четко указать что мы хотим получить на выходе, какие цели преследуем и как достижение этих целей будем контролировать. Ставьте перед системой реальные четкие цели и все получится. Поэтому считаю, что идеально составленная проектная документация, если не позволит спасти проект, то, по крайней мере, минимизирует риски неудачи проекта. Если на этапе ТЗ не удается четко определить цели, то становится понятно чем это все может закончится. К тому же, первую аксиому автоматизатора: "Нельзя автоматизировать хаос, ибо получится автоматизированная хаос" никто не отменял .

Цитата:

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

Я говорю про внедрение в коммерческих структурах, вы об внедрении в госсекторе.

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

Цитата:

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

Да, был пример - заказчик не указал предельный срок обследования. Сам и виноват - т.к. граничных сроков нет, подчиненные в первую очередь (а нафиг нас отвлекают!), внедренцы во-вторую (мы ходим-ходим, а всем некогда, отмахиваются, информацию из-под палки выбиваем) халявно относились к работе.

Заказчик и не должен сроки указывать, грамотное составление проектной документации, а договор это то с чего начинается проект, лежит на интеграторе. Именно интегратор является специалистом по внедрению информационных систем и знает подводные камни. Интегратор должен правильно организовать работы. Согласовать график посещений, распределить обязанности по предоставлению информации, причем не просто придя в бухгалтерию со словами: -"Мария Ивановна вам директор сказал рассказать мне о...", если нужно закрепить это приказом, проведением совещания с назначением ответственных и т.п. Таким образом на интеграторе лежит обязанность по организации работ по проекту в целом. Необходимо правильно организовать не только своих сотрудников но и сотрудников клиента. Вообще, это тема сложная и в рамках одного поста ее не раскроешь.

Цитата:

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

В нормальных компаниях пляшут от Дизайна проекта (там описываются все бизнес процессы, "хотелки" вплоть до конкретной кнопки и столбца с указанием конкретной стоимости за каждый элемент).

Жаль, что вы не ответили на поставленные мной вопросы, выша точка зрения была бы более понятна:

Цитата:

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

ВОПРОС: Вы описываете только дополнительно создаваемые поля, кнопки формы или существующий функционал тоже описывается?
ВОПРОС: Клиент говорит: Все ок меня все устраивает, но вот эта и эта, и вон та форма дорого, платить не буду. Что делаем?
ВОПРОС: Где документация по проекту? Где инструкции пользователей и конкретных рабочих мест? Когда появляется эксплуатационная документация?

Я решительно не понимаю что вы продаете клиенту? Набор форм таблиц и кнопок с ценой по каждому пункту? Зачем клиенту информация о том, что "прикрутить" к аксе, например, справочник доверенностей стоит 3 рубля 57 коп? Что он будет с этой информацией делать?

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

Цитата:

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

Что такое Технический, Рабочий проект? Если я правильно понимаю, это внутренняя документация интегратора, которая к заказчику не имеет ни малейшего отношения (он за них не платит).

Посмотрите ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ.

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

Рабочая документация - грубо говоря, это комплект документации по АРМ. Инструкции, описания и т.п.

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

Цитата:

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

Почитайте методологию Sure Step подробно - как я понял, Вы о ней не знаете.

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

Цитата:

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

Понятия не имею, как в госсекторе - как я понял из Ваших слов, там на этапе ТЗ распиливаются все деньги и до внедрения не доходит.

Ничего вы из моих слов не поняли ...

Цитата:

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

Да каких проектов с фиксированной ценой дорасти? А я что пишу - все проекты у нас с фиксированной ценой! Стоимость рассчитывается исходя из объема работ и неизменна!

Ок. До сего дня вы как-то работали. Спорить не буду.

Цитата:

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

Да, по поводу обследования - а Вы считаете, что заказчик должен платит по акту сдачи?

Да. Мало того мы так и работаем Хотя, возможны варианты и с частичной предоплатой. Ну уж точно не 60% стоимости всего проекта.

Цитата:

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

Ну да, а Вы сами обследование хоть раз проводили? Оно может тянуться от месяца (средние предприятия, до 100 человек) до года (1000 человек штата). И что, интегратору забесплатно этот год работать?

Обследования проводил, на заре карьеры. Сейчас обследование как таковое не проводится. Скорее это можно назвать изучение объекта при написании ТЗ. К тому же часто сталкиваемся с ситуацией, когда у клиента в принципе отстутствуют некоторые бизнес-процессы, поскольку старая система или методы работы строились совсем по-другому. Например, у клиента был обычный склад, адресного хранения не было. Теперь клиент "дорос" до необходимости использования адресных складов + терминалы + и т.д. Что тут обследовать? У клиента все процессы остались: приемка, отгрузка, инвентаризация. Только выполняться процессы будут по-другому. Зачем тратить время на обследование старых процессов, если они в принципе видоизменятся? Не лучше ли сосредоточить силы на изучение того, как надо что бы это работало?

Цитата:

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

В договоре на обследование (анализ) указывается конкретно предельное количество часов, затраченных на обследование (например, по отделам) и его стоимость. В госструктурах обычно идет 60% предоплата на все проекты сразу, потом по закрытию этапов.

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

Цитата:

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

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

Грамотное составление документации позволяет уменьшить риски и влияние некоторых факторов. Безусловно, это не панацея.

Есть еще один момент, но скорее всего он не характерен для РФ, по крайней мере пока. У нас в РБ есть такой орган - Госконтроль, наверное аналог вашей Счетной палаты. Только у этого "органа глубокого бурения" есть полномочия не только проверять и штрафы выписывать, но и реально посадить могут. Так что, грамотно составленная документация помогает не только уменьшить риски проекта, но и, извините, зад***у прикрыть, в случае чего.

Цитата:

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

А про вину стажеров (топик) уже и забыли?

А стажеров никто не обвинял. Так что вины у стажеров никакой нет.
Правда, я немножко увел тему в сторону документации .

[dmitryul]

Lz_, Вы внедряете по ГОСТ, лично я и многие другие мои коллеги - по Sure Step (впрочем, эти методологии похожи).

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

<QUOTE>Я решительно не понимаю что вы продаете клиенту? Набор форм таблиц и кнопок с ценой по каждому пункту? Зачем клиенту информация о том, что "прикрутить" к аксе, например, справочник доверенностей стоит 3 рубля 57 коп? Что он будет с этой информацией делать?</QUOTE>

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

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

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

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

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

Да, мы продаем на обследовании часы. Разумеется, сроки обследования, затраченные часы на каждый из участок фиксируются и если фактически времени и ресурсов потрачено больше (обосновано) - клиент это оплачивает. Да, доработку он тоже оплачивает, если какие-либо бизнес-процесы поменял уже в процессе написания документа. ИМХО, я считаю обязательным со стороны клиента оплачивать все дополнительные часы при обследовании, если он отказывается - это проблемный клиент и стоит заложить дополнительные риски при внедрении (увеличить стоимость, увеличить сроки "на всякий случай").

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

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

Или в Белоруссии внедрение стоит так дорого, а сотрудники так дешево, что интегратору можно соглашаться на такие кабальные для него условия? У нас в РФ норма стоимость часа внедрения для клиента = 3-4 зарплаты сотрудника, т.е. половина пойдет на налоги, оставшиеся части - зарплата и прибыль интегратора (50-100% от ФЗП).

У нас Дизайн обычно занимает по времени месяца два-три, рабочая документация - месяц. Не знаю, сколько по времени займет написание всей документации в соответствии с ГОСТ, но подозреваю, что намного больше. Время = деньги.

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

Госконтроль проверяет документацию на грамотное составления при внедрении АСУП на предприятии? Мда, даже не знаю что и думать - вот гайки в РБ закрутили, однако....

[sukhanchik]

2 Lz_ и dmitryul:
У вас обоих разные цели внедрения. Отсюда и разные методологии.
У Lz_ цель - внедрить - некоторую функциональность. Например, функциональность работы с доверенностями. Что она из себя будет представлять - неважно - для этого будет написано руководство пользователя, в котором будет написано что куда нужно жать. От заказчика требуется предоставить лишь общие пожелания (чтобы была возможность учитывать срок жизни доверенностей, кому и когда выданы и т.д. и т.д.). Будет справочник доверенностей с двумя, тремя кнопками или розовыми бантиками - заказчику - неважно - он свои требования выставил и получил оценку - что эта функциональность будет стоить столько-то.
Важно - внедряемая функциональность никак не зависит от наличия ее в системе, т.е. она может присутствовать в системе / быть новой / быть частично реализованной в системе. Руководство пользователя будет содержать описание всего процесса. Просто руководство пользователя будет написано либо по стандартному функционалу, либо по написанному. И здесь функциональный дизайн уже фактически становится ненужным (конечно какие-то крупные задачи могут детализироваться и дополнительно согласовываться, но это уже согласование нужно больше чтобы в процессе разработки уточнить некоторые (возможно пропущенные) непринципиальные по отношению ко всей функциональности детали).
Для реализации этого и подходит ГОСТ34.

У dmitryul цель - сделать то, что хочет заказчик. Т.е. быть по сути - программистом-аутсорсером, которому нужно сформулировать задание заказчиком и дать программировать. Консультант здесь выполняет роль секретаря-машинистки - заказчик диктует, а он записывает, иногда, правда вставляя от себя слова, понятные программисту. Программист же сдает конечный код (с тестированием, переносом начальных данных, оптимизацией БД и т.д.). Для реализации этого и подходит Sure Step. Хочу особо отметить - что Sure Step достаточно четко требует описания функциональных требований, которые реально не нужны заказчику в процессе его работы. Они нужны разработчику для разработки и заказчику в момент принятия работы, но совершенно не нужны ему в дальнейшем. А вот про руководства пользователей, которые нужны заказчику в дальнейшем для обучения новых сотрудников ничего в Sure Step я не нашел написанного. Т.е. Sure Step этого не предполагает - и это логично, т.к. цель Sure Step - сдать работающий код, а не перенести бизнес-процесс заказчика в режим работы в системе.