Начинаем работу по проекту перевода отдела логистики (от адресного хранения, до EDI) на 1С. Нахожусь со стороны Заказчика. Определен оптимальный подрядчик и с ним ведется предварительная проработка. Далее участие будет предложено еще нескольким подрядчикам.

Специфика проекта:
1. Невозможность разбить проект на блоки.
2. Крайне высокий уровень кастомизации.
3. Отсутствие штатных специалистов 1С и невозможность привлечь их в небольшой город за вменяемые деньги.
4. Работа в режиме 24/7.
5. Значительная сумма затрат по проекту.
6. Наличие самых разнообразных штрафных санций от сетей в случае несвоевременной поставки товара.
7. Простой дня складского терминала оценивается среднепотолочно более 20 млн рублей.


Вангую. Заключаем договор с интегратором. Год продуктивно работаем, тестируем, работаем, тестируем, обучаем, подписываем промежуточные акты, платим деньги, работаем, подписываем, платим, работаем, подписываем, платим, и т.д.
К запуску более 50%, а я так подозреваю все 70% будут уже интегратору оплачены.
Далее "завтра мы работаем в новой системе". Запускаем по сценарию. И тут система оттестированная перетестированная начинает выдавать кренделечки крендельки. Эти "хлебуболочные изделия" могут привести к потерям и штрафам, которые будут превышать впринципе всю стоимость договора с интегратором.

Тут возникает дилема.
1. Если мы предъявим это интегратору он в лучшем случае просто свалит недополучив свои 30% по проекту. Мы у разбитого  корыта.
2. Если мы попытаемся заложить риски в договор в виде "интегратор несет ответственность за все реальные убытки" - такой договор никто не подпишет.
3. Если мы попытаемся указать в договоре, что 50% суммы интегратор получает после успешного запуска, то стоимость договора автоматически сильно увеличивается, т.к. интегратор захочет нивелировать свои риски.
4. Выстраивать доверительные отношения с интегратором - согласен, но не на много миллионных проектах.

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

тестируете и работает, а потом вдруг бац и нет?
Включай нагрузочное тестирование и автоматизированное тестироание всех основных операций

>1. Невозможность разбить проект на блоки.

уже перестаю верить в эту латынь

Вы все одним махом внедрить хотите? Вчера работали по старому а сегодня уже по новому? Проблемы в запуске конечно будут. Это нормально я считаю.

(1) ибо перед стартом как обычно описывается 100500 строк кода нужного еще вчера и пол программы перестает работать ибо проверять некогда - завтра запуск

*дописывается

>За чей счет банкет?

за ваш - тут даже гадать нечего

(0) Хотите свои косяки перевалить на внедренца и кинуть его на бабки? И ищите советов как это лучше сделать?

В договоре что написано?

(4) но конечно это никак не спасет от того что тз поставленно некорректно изначально

(0)пригласите толкового рук. проекта

(9) А что, толковый возьмет на себя бизнес-риски клиента?

(10) Ну почему, добавляем еще 40-60 кк к стоимости контракта, и вперед ;-)

(10)у толкового РП таких вопросов как в (0)и(10) возникать не будет

(0) не ты 1-й, не ты последний, если на уровне предпроекта не пожмотились на нормальную команду, то проблем с простоем не будет, мы завод переводили с 3 ярдовыми годовыми оборотами за 1,5 месяца подготовки, целиком, ничего.

А если набрали студентов, то вперед ;-)

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

(10) Толковый рп обрубит бесполезные хотелки в начале проекта ;-)

(15)да, да, а затем его "отрубят"

(14) Просто люди не хотят платить 100-150 лямов за проект и подписывать интегратора на риски, а хотят за лям-2 сделать проект, это нормально ;-)

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

(0) Вменяемые деньги.
Это средняя зарплата в поселке?
Или средняя зарплата программиста в Москве?

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

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

- У меня завтра отгрузка на АШАН, а я до сих пор не могу подобрать короба. Программа зависает.
- У нас у всех висят компьютеры. Куча блокировок. Что делать? Водители нервничают, так мы попадем на миллионые штрафы.
- Остатки по адресному хранению расползлись. Мы срываем отгрузки. Чтобы привести адресные остатки в норму нам необходимо закрыть склад на три дня на проведение инвентаризации. Кто за это будет платить?
- Что происходит с программой. Мы не можем руководителю компании уже неделю дать баланс по остаткам и движениям. Что мне говорить?
- Не подливаются короба продукции, которая пришла на наш склад в Омске. Машина стоит с пяти утра и не может выгрузиться. Если дальше продолжится - транспортная компания выставит нам штрафные.
- Мы не можем принять продукцию из производства. Там накопились безумные остатки. Им некуда складировать. Если так дальше пойдет - мы остановим производство. Вы представляете какие это потери?

[К запуску более 50%, а я так подозреваю все 70% будут уже интегратору оплачены.
Далее "завтра мы работаем в новой системе". Запускаем по сценарию. И тут система оттестированная перетестированная начинает выдавать кренделечки крендельки. Эти "хлебуболочные изделия" могут привести к потерям и штрафам, которые будут превышать впринципе всю стоимость договора с интегратором. ]

именно так у многих и происходит )))

(11) Я бы не согласился. Согласен по справедливости - если я разделяю риски клиента, то участвую пропорционально в разделе его прибыли.

(20)
Эти риски всегда за счет заказчика.
Можно подписать на штраф.
Но цена проекта тут-же вырастет на сумму штрафа.

Так что правильно смотреть на это как на премию за успех.

(20) в договоре были требования к быстродействию/времени отклика?
в договоре было предусмотрено нагрузочное тестирование?
остатки по адресному хранению выводятся локалкой в процессе. иначе система адресного хранения не работает от слова нихрена.

(20) А вот этот опыт сильно увеличивает риски подрядчика.
Так как с вашей стороны персонал уже пережил одних интеграторов.
И никого не уволили.
Это успешный опыт для сотрудников.

(25) так и интегратора не расстреляли... :-9

(20) Нагрузочное тестирование на этапе сдачи помогло бы значительно

(20) Добавьте к этому:
-пользователь не умеет(не хочет) работать с программой и жалуется что она не работает.
- и еще +100500 примеров

ну и конечно на такой проект нужен знатный нагибатор.
Тот что легко нагибает владельцев заводов, газет, параходов

>>3. Отсутствие штатных специалистов 1С и невозможность привлечь их в небольшой город за вменяемые деньги.

Уже ваши проблемы и ВАШИ РИСКИ.

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

(29) в качестве РП

очень много проектов проваливается из-за саботажа и хлипенького РП

(32) БОльшинство.
это основная причина

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

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

У нас в текущей системе была проблема на второй месяц эксплуатации. Мы обнаружили, что из-за внесения изменений в механизмы расчета начали портиться посекционные остатки. Вовремя увидели. Поимели море головняка. Если бы обнаружили днем позже, то пришлось бы остановить отгрузки, закрыть склад на три дня и проводить инвентаризацию по адресам. Хотя тогда инвентаризация занимала не три дня. Неделю. Жуть.

Нагрузочное тестирование это же синтетическая вещь, которая лучше чем ничего, но не является панацеей.

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

>за нормальное вознаграждение и жилье

вы с кем сейчас говорили?

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

но платить за снижение этих рисков живыми деньгами - это для лохов.

плюс слабая проектная культура в конторе...

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

(20) Вы не указали проблемы, которые связаны с интегратором. На кой ляд тут ваш плач Ярославны и констатация того, что ваши сотрудники не умеют работать с программой? Более того, впадают в истерику и шантажируют.

К интегратору какие вопросы?

(35) На самом деле не все так плохо. Руководство нашей компании готово платить любые обоснованные суммы внешним Исполнителям, а вот со штатными есть трудности. Но я работаю над этим.
Акцент на слове "обоснованные". Я не нагибаю руководство. К АйТи тут относятся хорошо.

(35) Ну а как по другому ?
а нормальное вознаграждение и жилье
Где спецам жить? под забором и жрать доширак?
Такие проекты по определению без команды спецов не запускаются и не делаются, или они изначально обречены на провал.

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

(33) +100500
саботаж, причем часто топ-ов

для возможности реализации любого проекта нужно 3 вещи

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

если хоть одного из пунктов нет - считай будет болото с непредсказуемым результатом

(36)[К интегратору какие вопросы?]
почему он отказывается работать за ТС-а

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

(37) [ Я не нагибаю руководство. К АйТи тут относятся хорошо.]  как-то не соизмеряется

(0) Рассуждаете о том как возможные убытки переложить на интегратора, тогда нужно обсуждать и разделение прибыли(!) с интегратором при успешном запуске.
На мой взгляд, по такому проекту компетенции должны быть собранны внутри компании, а на подряд отдавать только кодинг

наверное продукт выбрали не правильный )

(42) Хороший вопрос, правильный.

(35) "плюс слабая проектная культура в конторе... " - рассмешил...

(0)  Саботаж со стороны сотрудников как то совсем забыт.  А это на 90% проектов случается.  
(37)  Особенно в отсутствии мотивации этих штатных сотрудников.   Ибо им и без вашей автоматизации хорошо,  а вы их заставляете работать при внедрении сверхурочно и никакого профита от положительного внедрения новой системы иметь не будут.

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

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

Ваша "панацея" называется "План управления рисками". Этот документ составляется на этапе планирования проекта, согласовывается сторонами и является неотъемлемой частью плана проекта. В плане управления рисками описывается возможная реакция на каждый риск, кто и в какой мере несет ответственность. Резервный фонд включается в бюджет (но не в смету!) проекта. Т.е., определяется некая сумма на покрытие рисков, но это не значит, что вы всю оплатите Исполнителю.
Вообще, управление рисками — отдельная и обширная часть управления проектами. Материала по этой теме вагон. Можно начать с этой презентации https://pmi.ru/profes/Arkhipenkov_07_04_2009.pdf

(52) Ого, интересно, есть ли интеграторы, которые готовы совместно с Заказчиком проработать управление рисками. Мне кажется это чем-то из области фантастики.

(53) Вы смотрите в книгу, а видите фигу. Команда проекта не разделяет риски предприятия, она управляет рисками ПРОЕКТА. А это две большие разницы.

(53) У меня сейчас есть проект с процентом от прибыли ;-)

(54) Скажу честно, что управление рисками для меня обычно заканчивалось нестандартными договорами, санкциями, штрафами, сценариями, договоренностями на уровне руководителей компаний, и т.д.
Но теория управления рисками меня обошла стороной. Буду RTFM.

(53) есть конечно, вот например http://www.croc.ru/

только учтите, если что они вас сожрут не смотря на ваши простои в 20 лямов в день

(55) Как обычно все завалишь?

(57) У них штат юристов наверное человек 50. Они и управляют всеми рисками. :))

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

(20) - У меня завтра отгрузка на АШАН, а я до сих пор не могу подобрать короба. Программа зависает.

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

- У нас у всех висят компьютеры. Куча блокировок. Что делать?
Сервера, узкие места вопрос должен был сняться нагрузочным тестированием.
Водители нервничают, так мы попадем на миллионые штрафы.
Чем заняты программисты? Чем заняты консультанты, чем занят РП заказчика?

- Остатки по адресному хранению расползлись.
Почему?
Мы срываем отгрузки. Чтобы привести адресные остатки в норму нам необходимо закрыть склад на три дня на проведение инвентаризации.
Адресные склады инвентаризируются по ячейкам- нач склада под увольнение

Кто за это будет платить?
Вот пусть нач склада и платит, он мат ответственное лицо

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

- Не подливаются короба продукции
Нагни программеров чтобы вышли в 5 утра, у вас должен был быть пункт в контракте, правда это доп деньги, но это копейки
, которая пришла на наш склад в Омске. Машина стоит с пяти утра и не может выгрузиться. Если дальше продолжится - транспортная компания выставит нам штрафные.
- Мы не можем принять продукцию из производства.
Причина, ответственный, наказание, скорее всего нач склада под увольнение 2-й звонок

Там накопились безумные остатки. Им некуда складировать. Если так дальше пойдет - мы остановим производство. Вы представляете какие это потери?
Эти потери связаны с экономией на грамотных управленцах и внедренцах ;-)

(58) ;-)

(0) Да и на Кренделя не фиг пинять

(60) Интересный подход. На этапе запуска во всем виноваты будут айтишники Заказчика и Исполнитель. По большому счету тут надо видимо всех от рядовых сотрудников до высшего руководства собрать в актовом зале и сказать, что 1 января 2018-го года у нас будет революция. Будет полный зомбоапокалипсис.
Если запуск пройдет хорошо - то пенять что пересмотрел рен-тв.
Если запуск пройдет плохо - то "я же предупреждал". :)

(62) :)

(63) Если ты не прошел нагрузочное тестирование, запуска не будет ;-)

(63) Таки да. Любой переход на новую систему - революция и шок для сотрудников предприятия. А Вы как хотели?

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

Ну как бы и получили экономное внедрение, все факторы налицо ;-)

(65) На заводах 24/7 не внедрять процессы To Be

Не возможно начать работать с новой системой завтра, даже если в ней все идеально настроено. Юзеры просто будут ошибаться и идеальную систему сведут на нет. Сколько часов перед запускам предыдущей системы каждый пользователь проходил обучение по работе с ней? Если менее 40 то даже если все ок с программой человеческий фактор ее убьет. А интегратор не может к каждому юзеру учителя поставить.

(67) маленькая ремарка (при переходе на новую систему)

причем 40 это для юзеров с примитивным набором действий для более сложных процессов может и 400 быть мало.

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

У самого так было что там учить инструкция в 20 пунктов 3 странички. Проверки от дуроков на каждой кнопке и цифре.
Пока народ не провел отдельного обучения программа не работает, постоянно глючит, тормозит и т.п.
Как руководство выделило по 1 часу в день на обучение, через 2 недели та-же программа работает идеально.

Сдается мне что чуваг (0) опять ищет сотрудников за три копейки. На скуль ру вакуху публиковал, нашел кого?

Вы специалист? с чего вы взяли что невозможно разбить проект на блоки? Как связана программа и кастомизации непонятно. 3 пункт вообще смешон глупо надеяться что руками интегратора выполнять работу штатника будет дешевле и он сможет обеспечить постоянно нужную скорость реакции учитывая п. 4,6,7

(73) Не не. Уже не ищу. Прошу не продолжать, а то опять забанят. Всех уже нашел. Осталось согласовать с руководством облачные зарплаты.

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

(75)
Режутся риски.
За это платишь трудо-затратами на интеграцию блоков.
Все честно.
Либо риски либо затраты.
Тебе дешевле или надежнее?

(52) спасибо!

(0) своя сильная команда. без вариантов.

(78) Ахаха

(75) "Осталось согласовать с руководством облачные зарплаты. "
Значит основная работа впереди.

Говори что это самый минимум.
С таким рассказом руководству не продать.

Облачные это сколько?

(79) ха не ха, но риски кроме внутренней службы ИТ никто более на себя не возьмет.
ну... либо осваивать бюджеты, каждый год меняя интеграторов.  в принципе 2-3 интегратора и квартира с дачей в МСК обеспечена

(81) Это само собой.
Но ему плюсом хочется результата.... странно.

Тем более что это минимум второй интегратор уже.

(81) при этом руководство чувствует себя мужиком из анекдота "Третьего петуха покупаю и опять голубой".

(81) Какие риски ты берешь идя на работу? Акстись, нет у тебя рисков если в должностной инструкции не прописано что ты отвечаешь баблом, а у тебя это не прописано!

(84) буду ли я тут работать далее или нет. К примеру, для директора ИТ это значимый риск

(85) Чот ржу, действительно это большой риск

(86) ну смех без причины всем известный сиптом какой болезни.

(83) ну примерно так, хотя оно обычно тоже в доле

(85) Ни разу не видел как проектная команда разбегалась на этапе внедрения?

(88) практически у любого интегратора это осознанная стратегия.

(85) ну вроде ТС и так ИТ директор, но это не помогает

(89) А штатных товарищей ты не застал?

(90) так он и не хочет брать на себя риск =)
(91) нет. если чел свалит до запуска, то вопрос к начальнику и его рекомендотателю: нафиг он его взял

(92) И отказов выходить в нерабочее время ты тоже не встречал?

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

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

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

(95) Потому что я видел этих "своя сильная команда" и могу показать результаты этих самых сильных ;-)

(0) куда ехать-то? Уже чемодан собрал)

(97) а я видел и так и сяк и эдак. Могу сравнивать с любой точки зрения.

(98) Ты уточни сначала размер облачной зряплаты

Специфика проекта:
1. Невозможность разбить проект на блоки.
2. Крайне высокий уровень кастомизации.

п.1 - всегда можно выделить законченные этапы, это могут быть или запуск по отдельным участкам, или послойное внедрение, когда сначала запускается упрощенная технология работы, потом идет постепенное усложнение по участкам
п.2 - это только внедрение БП может заключаться в setup и то не всегда, на практике всегда допиливание типовых решений. Ну и своих гениев от логистики двигайте в сторону типовых решений.

жизнь показывает, что как только Заказчик начинает нудить про риски значит на стороне Заказчика никто ничего делать не будет и проект на 99% провальный

(99) Нуну, если заказчик не смог подобрать команду на этапе выбора франчей, то он сразу же выберет себе эту же команду на этапе отбора спецов- Андерсен отдыхает

(103) см (102)
там все на 100% верно.
либо заказчик находит у себя ответственного, либо проект не жилец

(104) А я и не спорил про ответственного ;-)

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

В п (60) который ты ессно не читал, я тебе сразу и определил куда бы я копал в момент завала проекта ;-)

(97)
Ты видел плохих.
Потому что к хорошим варягов не приглашают.
Это уже выборка специальная.

(107) "моя хата с краю" . Это обычная позиция интегратора. :)
(108) +1

(108) Ну они мои основные клиенты, так что я не жалуюсь ;-)

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

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

Других, где свои смогли ты не видишь, так как не ищут они рулевого.

(111) Да это понятно

Мне кажется что Заказчику надо уволить ТС-а...

Основная проблема в нём

(41) Закладка

(0) Чуваг, а сколько пользователей?

Вообще главный пройопщик сам ТС. Ибо он фактически РП со стороны Заказчика.

(75)сколько там "облачные" зп, так чисто поржать

Пользователей около 40 одновременных.

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

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

А вот насчет смены руководителя службы ИТ на то время пока я буду РП со стороны Заказчика - это да, витает в воздухе. Сидеть надо на одном стульчаке.

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

(120) Я не вижу тут сложности мегапроекта

(119) >>Пользователей около 40 одновременных.

Пипец, фигня какая-то. Сделали из мухи слона.

(119) Город? ))

(120) Сам ты фикция, без РП со стороны заказчика ничего не взлетит.

Город какой?

(123) Донецк

(126) ростовский который

(0) А рассматривается ситуация, при которой все срывы будут именно из-за вашего персонала?

(127) Вроде*

(128) Они инвентаризацию адресного склада на лету провести не могут, как думаешь?

(124) Вы предлагаете вести параллельно два проекта - один заказчиком, а другой внедренцем? И каждый со своим руководителем? :)

(131) Эээ, ты же внешний товарищ, причем еще и на ниве результата подрабатываешь ;-)

(131) Нет блеать я предлагаю РПшнику самому строить исполнителей Заказчика и потом пить коньяк и кидаться на людей от нервов как ты

С 40 пользователями устроил тут плач Ярославны, это просто жесть какая-то.

(134) Судя по (130) нужен просто козел отпущения!

ГОД!!! делать проект на 40 пользователей, завалить, потом опять искать НЕСКОЛЬКИХ подрядчиков - да за такое расстреливать надо.

Во всём виноваты программисты!

(133) Про "решальщика" было выше :) Он никак не РП.

(136) 40 активных это как минимум 20-30 постоянных, и 4 смены по 10-20 человек

(138) Я это называю РП со стороны заказчика

Извини Джинн, но дергать спонсора проекта чтобы согласовать график встреч менеджера по закупкам- это зашквар

(139) Чего-чего? 40 активных это 40 активных, не надо фантазировать.

(142) Читай ТЗ, предприятие 24/7, это значит 4 смены

(143) Я делал кондитерскую фабрику и хлебозавод, круглосуточная работа, 60 и 30 активных пользователей, чего ты мне лечишь?

(144) 30 активных- а пользаков сколько было?

(141) Дергать нужно не спонсора, дергать нужно того, кто не организовал команду проекта, не выделил ресурсы под проект. Менеджер по закупкам должен уже заранее знать, что он в команде, что определенное количество часов его рабочего времени  принадлежит РП, что РП имеет право ставить ему задачи в рамках проекта и спрашивать за их выполнение. Если это не делать, то и появляется "решальщик", на ходу выискивающий жертву, которая в данный момент наименее ценна для компании и озадачить его всякой фигней. Это прокладка между РП и ресурсами.

(145) Я не считал

(147) Ну так посчитай и сравни с моим расчетом ;-)
(146) Мне проще иметь решальщика, который будет спонсору докладывать текущее состояние проекта, и предпочитаю чтобы спонсор выбрал своего человека ;-)

(148) Кренделёк, чего ты хочешь сказать? Ну было их ночью раза в 2 поменьше, на что это влияет?

(149) На то, что кто-то должен был позаботиться о том чтобы  обучить их, и сопровождать хотя бы недельки 2, очень плотно ;-)

А так я такого рода проект в одного консультанта и одного разраба закрывал

(148) Я же не против. Я против двух руководителей у одного проекта. Раздавать задачи, следить за их выполнением, контролировать план-график и т.п. должен один человек. И получать как пряники, так и по голове.

(151) Был и конс и разраб. Я вообще этот пример привел не для того чтобы с тобой померяться, а для того чтобы показать что ТС занимается куйнёй.

(153) Я просто привел численность проектной команды для такого рода проекта ;-)

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

(155) Не думаю, смысла тогда в старте топика 0

(155) Я бы начал трясти нач склада, уж очень похоже на него

А надувание щек и делание вида работы

(158) Хехехе, в пятницу вечером? ну как же без этого

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

завтра запуск

http://img0.joyreactor.cc/pics/post/гифки-it-программист-удалённое-3702684.gif

(161) Зачет

(161)
Пятнично!
Как в прочем и вся тема стеб

(155) Есть смысл показать руководителю что риски ж-пы неизбежны.
И самому еще раз убедится.

(151) > да да, wms-ку с кастомизацией в одного разраба. Сказочник.

+(165) так даже саповцы не могут с учетом того что они свои БП натягивают.

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

(167) компания ТС хочет перенести существующую модель (на мой взгляд примитивную) на платформу 1С, т.е. ТС хочет доказать руководству какой он был умный и шустрый в разработке своей самоделки

(165) Тогда требования к вмске в студию? На 10-к сборщиков

+ если не хватало ресурсов, вмс спокойно выпиливается на следующий этап

(170) так у него я так понял весь проект это и есть wms. Смена одной на другую. Иначе разбить на этапы было бы проще. А wms это такая "песня".

(171) Чистую вмску я не внедряю, не мой профиль, да у меня и под это дело команда во главе с бывшим нач склада есть

(172) видать нач склада у тебя нестандартный тертый калач. Обычно нач склада зацикливаются на конкретной технологии к которой они привыкли и тащат её за собой. Тех кого я видел на проектах они все больше из логистики произрастают.

(173) Он просто будет решать вопросы в зародыше ;-) Типо не можем провести инвентаризацию- идите считайте ;-)

Внедряю ВМС
Стучись

(146) Это по классике, но в реале это из области фантастики. В нашей реальности у Заказчика должен быть уполномоченный человек с карательными функциями, сильно замотивированный на результат проекта.

Ну как всегда
Недорого
Качественно
Быстро
И все это в одном флаконе?!

(177)
> И все это в одном флаконе?!
угу, в качестве бесплатного контента )