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

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


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

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

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

(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)
> И все это в одном флаконе?!
угу, в качестве бесплатного контента )