История одного неуспешного проекта

Управление - Управление проектом

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

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

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

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

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

Основной причиной перехода было постепенное «умирание» базы из-за объема: она занимала под сотню Гб (тут могу ошибаться), и еще имела несколько распределенных узлов: документы еле «ползали», стоимость материалов уже не считалась. А бизнес расширялся, и собственники опасались, что еще одного года база не переживет.

Хотя речь шла только об управленческом учете, окно для перехода в новую конфигурацию было очень коротким – два месяца: апрель-май. В остальное время шла закупочная компания и подготовка к массовой новогодней корпоративной «сувенирке» - основному доходу Заказчика.

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

В то время требование: торговля + себестоимость + бюджетирование - означали УПП. Тем более, что мы в то время специализировались в основном на внедрении данного программного продукта.

Первую фазу внедрения – проработку Функциональной модели - мы начали в мае-июне. Уже сразу стало понятно, что программный продукт в части торгового блока не подходит им на 90%. У них было отдельно ведение клиентов и партнёров, деление номенклатуры на сегменты с разным ценообразованием для разных категорий покупателей. Были справочные адресные склады и подписки клиентов на события. И еще много чего, что в то время уже было частично реализовано в УТ11.

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

 ФМ на УПП шел очень тяжело. Пользователи не видели нужного им функционала, и буквально все приходилось объяснять друг другу «на пальцах». В итоге концепт мы все-таки защитили, но он предполагал почти 200 доработок объемом под 4 тысячи человеко-часов. Бюджета на такое дело у них не было, так что от половины (!!!) доработок было решено отказаться, а оставшуюся часть поделить пополам с их ИТ-службой.

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

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

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

Все это «вылезло» на этапе первого контакта системы с реальными пользователями, и привело к 400м часов запросов на изменение (то есть почти 50% от нашего объема доработок). Примерно столько же «прилетело» и на ИТ-службу, что, конечно же, не улучшило наших отношений.

Но сначала, до нашего эпического «первоначального обучения ключевых пользователей» разразился кризис в самом кодировании: программисты мешали друг другу; в одни и те же справочники добавлялись одинаковые по смыслу реквизиты с разными названиями; накатывание одних доработок приводило к неработоспособности других. Причем, найти виновных было невозможно, потому что каждый кодировал свой кусок («к пуговицам вопросы есть?»).

Уже гораздо позже, по результатам полученного (через кровавые слезы) опыта у нас в фирме родился документ «Стандарты кодирования», в котором мы описали (и актуализируем до сих пор) основные принципы разработки.

Глобально с того проекта я вынесла правило «учись на чужих ошибках»: если ты чего-то не делал на проекте раньше, то сядь и подумай, что может пойти не так; поспрашивай народ на форумах, почитай переписку, литературу и так далее – в нашем бизнесе сложно придумать что-то действительно новое, чего раньше никто не делал.

Но в то время мы просто «бились головой о стену», съедая отпущенные на разработку часы и время. Своих проблем добавила и платформа, в которой от версии к версии хранилище работало все хуже и хуже: куски кода пропадали целыми блоками, уже протестированные доработки переставали работать; некоторые вещи пришлось реализовывать по нескольку раз. С тех пор мы с очень большой настороженностью относимся к любым обновлениям платформы в ходе проекта.

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

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

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

Сейчас мы, конечно, уже так не работаем. За 15 лет работы в этом бизнесе я еще не встретила заказчика, который может на этапе ФМ или даже ТЗ полностью осмыслить будущее поведение системы. Все равно на этапе эксплуатации вылезают вещи, которые надо подправлять. В определенный момент я приняла этот факт как данность, и теперь просто закладываю в стоимость доработок примерно 20% на их «допиливание» на ходу. Клиенту проще один раз пережить большой бюджет, чем каждую неделю бегать к собственнику с допниками.

Также в ОПЭ я закладываю время на работу программиста: просто на отчеты или печатные формы, про которые все забыли на этапе ФМ, и прочие «бантики».

Нужно ли в таких условиях согласовывать ТЗ? Да, нужно, потому что с ним можно в любой момент остановиться, отметая откровенную «ересь».

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

В первый же день прилетела вторая «атомная бомба»: как оказалось, выделенные в апреле ключевые пользователи тоже не владели полной информацией: были люди (а иногда и целые отделы), которые работали «чуть-чуть по-другому». GoLive Tracking рос как снежный ком, и в нем было 2 статуса: «исправить до завтра» и «исправить немедленно». Программисты (и наши, и их) работали по 14 часов в сутки, поедая часы на ОПЭ с экстремальной скоростью. В итоге заказчик «забил» на бюджетирование и «забил» на себестоимость. Весь бюджет был перенаправлен на доведение системы хоть до какого-то приемлемого состояния.

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

Акты нам подписали, но ни о каком положительном отзыве не могло быть и речи. Общий перерасход часов по всем работам составил 30%. Реальный перерасход – больше 50%.

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

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

Здесь надо себя просто переломить: основная функция РП – это двигать проект в нужном направлении и с нужной скоростью. Под «двигать» я имею в виду как своих спецов, так и Заказчика (то, что его сотрудники не горят желанием взваливать на себя доп.работу нормально – им за это редко доплачивают). В некоторых книгах по управлению проектам пишут, что РП на проекте вообще должен управлять только рисками: то есть постоянно прогнозировать (самому и с помощью проектной команды), что именно на проекте может пойти не так. И, самое главное, увидеть, что процесс где-то затормозился, объективно оценить причину и во время среагировать, чтобы не попасть в пресловутую ловушку «98-ми процентов».

В провале проекта почти всегда виноват именно его менеджер – в какой-то момент приходится это принять и начать работать над собой.

Закончить хочу словами Джо Мараско (за точность цитаты не ручаюсь): «проекты похожи на восхождение альпинистов – трудно планировать, важна слаженность команды и природа по определению сильнее тебя. Однако есть альпинисты, которые водят группы успешнее других».

Предыдующие публикации на тему управления проектами:

См. также

Комментарии
1. Игорь Мирошниченко (igormiro) 669 09.06.17 17:11 Сейчас в теме
Интересная статья. "Также в ОПЭ я закладываю время на работу программиста: просто на отчеты или печатные формы, про которые все забыли на этапе ФМ, и прочие «бантики»." - какие бантики?
2. rjhev korum (корум) 305 09.06.17 17:55 Сейчас в теме
(1)
какие бантики?

удобная справка по состоянию заказов, печать счета из заказа, загрузка прямо в документ из ёкселя и туча других плюшек, что щедро раскиданы по старой системе, о которых никто не вспоминает до момента ввода новой системы в эксплуатацию...
Lacrimosa0000; hilton008; +2 Ответить
3. Дмитрий Котов (rpgshnik) 6 09.06.17 18:08 Сейчас в теме
Такие статьи на порядок полезнее успешных внедрений.
корум; i1381215@trbvm.com; orfos; Leja; Kotta; Wrols; Maxis; Stim213; hilton008; Serega-artem; Бывалый77; АльфаАвтоПрограммист; FilatovRA; Overtone; DeD MustDie; Светлый ум; brr; AlexK_2012; FreeArcher; Samarin; serg_gres; smirnov.es; baracuda; white_sochi; Сурикат; davdykin; +26 1 Ответить 1
4. rav38574 (RAV38574) 71 09.06.17 23:49 Сейчас в теме
Беда в том, что пытаетесь воспроизвести то что было - зачем?
Используя типовой механизм, надо оптимизировать бизнес процессы клиента под них, а уж потом кодировка. Или смена типовой.
Начинать надо с бизнес процесса компании, а не то что было. В результате хотелок менеджеров приводится конфигурация к дому без фундамента. Просто не представляю зачем переписывать на 90%. Тогда уж ТЗ подробное и с 0 строго по ТЗ, а хотелки неучтенные, после сдачи проекта хоть годами дорабатывать. Чума а не внедрение у Вас было.
VladimirL; dimpson; Aleskey_K; Serega-artem; АльфаАвтоПрограммист; KazanKokos; baracuda; +7 Ответить 2
5. Геннадий Николаев (genayo) 10.06.17 07:35 Сейчас в теме
Как это все знакомо. Видимо, каждый франч должен пройти через такой проект...
stilet; 1СERP; +2 Ответить
6. Сергей (Che) Коцюра (CheBurator) 3382 10.06.17 08:58 Сейчас в теме
Как все знакомо
Какое ТЗ пилить?
Подробное? На больших да и не очень проектах когда заказчик хочет точно знать что он получит и за что платит деньги - нереально составить ТЗ которое описывает готовый результат да ещё с такой степенью подробности - на одно составление такого тз уйдёт куча времени и денег. Составляя подробное тз ты сталкиваешься с задачами заказчика которые лежат на стыках подразделений - начинается либо тупняк либо отпихиваете и тихое подсылание нафиг со стороны заказчика. Вынесение таких вопросов наверх либо существенно тормозит процесс тз либо вопросы решаются командирским решением руководителей заказчика и такие решения частенько полумертвые
Писать тз на уровне функциональных требований - всегда есть разногласия причём существенные как кто эти требования понимает.
И все становится непонятно...
7. Олег Дмитров (baracuda) 3 10.06.17 10:09 Сейчас в теме
Все прочитал с большим интересом.
Спасибо за цитату Джо Мараско, очень понравилась.
8. d4rkmesa (d4rkmesa) 10.06.17 11:23 Сейчас в теме
(4)
Может, потому что речь об УПП? Мне очень знакомо подобное внедрение, успешное правда, с самописки на базе 7.7 на УПП с доработками, правда, в другой отрасли(пищепром - производство + оптовая торговля + логистика, полный цикл). На типовой УПП уже бы на 2-й день все либо встало, либо как то работало с неимоверными усилиями сотрудников, которые уже на 2-й день устроили бы бунт, т.к. работать круглосуточно не может никто. Элементарный цикл: прием заказов - резервирование и оформление - планирование логистики - отбор и доставка по клиентам, уже на этапе логистики бы столкнулся с трудностями, т.к. фактически этого функционала в УПП нет. Ну допустим в Excel-е логисты все сделали, дальше у склада увлекательная задача - разложить все по машинам "по бумажкам" (распечатанным Торг-12). Плюсуем человеческий фактор - и доставка фактически либо сорвана, либо осуществляется с существенным опозданием. На след. день руководство дает всем по шапке и внедрение откатывается.
Dementor; +1 Ответить
9. Николай Переляев (nickperel) 1 10.06.17 13:20 Сейчас в теме
Спасибо, что вы продолжаете цикл.
Если захотите продолжить, раскройте подробнее практику работы с локальной ИТ - службой (управлением, отделом, просто отдельным программистом) или ответственным лицом.

Частая ситуация - после контакта с ключевым лицом заказчика (директором), приходишь к соглашению внедрять типовую и "оптимизировать процессы".

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

Если ультимативное требование - два месяца, то предлагаешь к этому строку начать работать на 50%, если все это время клиент будет учиться пользованию ERP.
С большими цифрам покрытия бизнес процессов никогда никто почему то не согласен.
Доработанное УПП портировать по функциональности, а не коду. Это не два месяца и сотни часов.
А то и год, как пойдет..
Тут могут сразу сказать, что хотели решение "с полки", никаких "с год.." и отвалиться. Это ладно..

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

Клиент может отвалится сразу, поняв что он сам - обязательная часть хода проекта. Это ладно..
Часто стрелка указывает на специалиста в штате - т. н. "программиста 1С". Что вообще означает это название в стране никто не знает.
И иногда это, внезапно, и есть программер старой системы , но он объективно не заинтересован. Он как бы все и так уже сделал и хотел бы работать над недостатками старой системы.

Если на месте "программиста 1С" сидит сисадмин, то может начаться разговор "...почему не SAP, это несерьезно..".
Но работу принимать он будет, участвовать - нет. Все попытки подходить с проблемами будет адресовать выше себя или в сторону. То есть в никуда.

Если это управление ИТ или отдел, все тоже самое, только роль "программист 1С" назначена группе людей. От этого дело бодрее не идет. Они даже саботируют с черепашьей скоростью :-)

И потом, во всех объявлениях о найме "программиста 1С" указано "не конфликтность". То есть наверно надо "не склочность", но человек из ИТ всегда опасается, что его участие могут интерпретировать как нелояльное конторе.

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

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

Сложился ли какой-то формат работы в проекте для локального ИТ, кроме того что они просто фактически переподчиняются подрядчику и исполняют все безусловно?
Простая механика отката сразу переводит отношения в подземный уровень и тоже ничего не решает и сильно может навредить.
ZUL_MTFKA; DeD MustDie; +2 Ответить
10. Николай Переляев (nickperel) 1 10.06.17 13:46 Сейчас в теме
Очень длинно написал, простите.

Но вижу по другим обсуждениям здесь, что проблема ключевая. С поправкой - кто организует проект. Если такая структура, как "Раздолье", то бюджет большой.

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

Может есть способы мало затратной интеграции подрядчиков?
11. Геннадий Николаев (genayo) 10.06.17 16:05 Сейчас в теме
(10) Проблема в том, что * получает руководство, а проблемы - ИТ служба. Понятно, что иногда у ИТ не выдерживают нервы :)
12. Геннадий Николаев (genayo) 10.06.17 16:10 Сейчас в теме
(11) Фигассе, тут цензура чтоле? ***
artfa; корум; Paradise.87; +3 Ответить
13. rav38574 (RAV38574) 71 10.06.17 18:09 Сейчас в теме
Всегда с клиентом обговариваю докручиваем типовой до ваших хотелок с минимальными изменениями, на с соглашениями, что всякие изменения типового обсуждается точно. Если сохранение типовой не важно, тогда свобода полная, но чтобы программист внес доп. поле не проанализировав что уже есть - это делитанство. Адекватный ИТ отдел кстати по моему опыту наоборот является аккумулятором хотелок и отсекает дурные идеи, что занимает много времени внедренца если он будет слушать эту чушь. Про ТЗ да сложно, да кропотливо, но на большой проект необходимость, иначе не оплата или неудовлетворенность клиента (меня развели на бабки)..
14. Александр alex_2h2008 (alex_sh2008) 5 10.06.17 18:21 Сейчас в теме
Не понятно, почему вы вообще навязали клиенту УПП, ведь прекрасно понимали, что придется переписывать? Может из правила "втюхать, а потом хоть пожар"?
15. Timeforlive S (timeforlive) 8 10.06.17 18:52 Сейчас в теме
(1) справочная информация и вовсе забывается (в т.ч. инструкции для конечных пользователей).
Сотрудники меняются и начинается бегство к программерам с вопросами "а куда дальше нажимать" или "ЧЯСНТ" (что я сделал не так).
У нас в фирме было так (у многих так).
16. Timeforlive S (timeforlive) 8 10.06.17 18:56 Сейчас в теме
хорошая статья, спасибо. Еще понравились иллюстрации, как раз в тему. Пора по 1С сделать аналогичные :)
АльфаАвтоПрограммист; +1 Ответить
17. Александр Рытов (Арчибальд) 2659 11.06.17 23:10 Сейчас в теме
Довнедрение системы было поручено ИТ-службе, в итоге они ее постепенно довели до ума, и работают на ней до сих пор.
О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) - привлечение "профессиональных" внедренцев.
Это сейчас уже понятно, зачем нужны интеграционные тесты, формализация требований к общим справочникам и так далее. Но в то время я просто решила набрать на проект побольше программистов

Классика. библия 50 лет назад было известно, что добавление программистов удлинняет процесс программирования. А теперь вдруг это опять открывают...
Респект автору за честность.
mitia.mackarevich; +1 Ответить 3
18. Ярослав Кулебякин (user770267) 11.06.17 23:15 Сейчас в теме
. Кому принадлежит проект?

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

Решение:
Убедитесь, что у вас есть поддержка высшего руководства. Должна быть прямая связь между топ-менеджерами компании и акционерами вашего бизнеса. Ключевое сообщение должно быть таким: «это произойдет, так что вы либо с нами, либо без нас» и убедитесь, что они не выберут второй вариант.
Как менеджер проекта, будьте внимательными, чтобы топ-менеджер не принял управление проектом на себя и не стал фактически руководителем проекта.
Lacrimosa0000; KazanKokos; baracuda; +3 Ответить 1
19. Ярослав Кулебякин (user770267) 11.06.17 23:15 Сейчас в теме
2. Привлекайте пользователей

Ошибка:
Отсутствие вводимой пользователями информации и недостаток их вовлеченности– рецепт для плохого проекта. Такая ситуация может быть вызвана образом мышления ИТ-департаментов: «мы знаем, что вам нужно», или недостатком интереса со стороны пользователей. В любом случае, такой ситуации следует избегать.

Решение:
ИТ-департаменту нужно время чтобы понять требования клиентов прежде чем предлагать любое техническое решение. Часто ИТ-департаменты ослеплены последними, самыми новыми информационными продуктами и стараются подогнать существующие требования под них. С другой стороны, для успешной реализации проекта клиенты должны выделить некоторое время и совместно с ИТ-отделом убедится, что все их требования были полностью обозначены. Удостоверьтесь в том, что вы поговорили со всеми акционерами компании и учли их требования, и в том, что они поддержат Вас на протяжении всего проекта.
20. Ярослав Кулебякин (user770267) 11.06.17 23:16 Сейчас в теме
Остановите расползание масштабов проекта

Ошибка:
Увеличение масштаба проекта – одна из основных причин неудач. Не знание точных итоговых целей проекта или потворство своим порывам энтузиазма – рецепт неудачного проекта.

Решение:
Убедитесь, что бизнес-план, требования и рамки проекта четко определены и задокументированы. Акционеры компании поняли их и поставили на них свою подпись. Жестко придерживайтесь установленного объема проекта и, если необходимо внести изменения, проведите их через процесс управления изменениями, где они будут задокументированы, будет подтверждена их правомерность и они будут утверждены.
21. Александр Губанов (gubanoff) 44 12.06.17 13:25 Сейчас в теме
(0) Картинки я бы убрал, отвлекают
olgerd666; Paradise.87; +2 Ответить 1
22. Сергей (Che) Коцюра (CheBurator) 3382 12.06.17 21:25 Сейчас в теме
(17) Арчи, собственники удавятся, но своему персоналу - лям не заплатят. заплатят на сторону.
Lacrimosa0000; Бывалый77; smirnov.es; KapasMordorov; brr; +5 Ответить 2
23. Евгений Грибков (1СERP) 996 13.06.17 12:11 Сейчас в теме
(1)
Спасибо. В дискуссиях в предыдущих статья коллеги просили поделиться опытом реальных не особо успешных проектов. Эта статья - первый такой опыт
24. Евгений Грибков (1СERP) 996 13.06.17 12:11 Сейчас в теме
(3)
Спасибо. Передам автору.
25. Евгений Грибков (1СERP) 996 13.06.17 12:15 Сейчас в теме
(4)
Вы, конечно, правы.
Только "на берегу" было ограничение:
Предыдущая система, вцелом, устраивала Заказчика. Причина перехода - преимущественно, технологическая. Поэтому клиент не особо был настроен на "оптимизацию бизнеспроцессов". Поэтому и основными заказчиками оказалась ИТ-служба, а не бизнес.
Больше мы на такое "не ведемся".
26. Евгений Грибков (1СERP) 996 13.06.17 12:23 Сейчас в теме
(14)
Цитата из статьи: "торговля + себестоимость + бюджетирование - означали УПП"
27. Евгений Грибков (1СERP) 996 13.06.17 12:26 Сейчас в теме
(17)
"О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) - привлечение "профессиональных" внедренцев."
- Не был бы. Переходить нужно было быстро, двумя людьми это сделать было невозможно.

"Классика. библия 50 лет назад было известно, что добавление программистов удлинняет процесс программирования. А теперь вдруг это опять открывают...
Респект автору за честность."
- Все читают теорию, но осознавать и использовать начинают после своих шишек. Об этом и пишет автор.
rovenko.n; +1 Ответить
28. Евгений Грибков (1СERP) 996 13.06.17 12:27 Сейчас в теме
(18)
В данном проекте один из собственников бизнеса - был куратором проекта и активно в нем участвовал.
29. Евгений Грибков (1СERP) 996 13.06.17 12:28 Сейчас в теме
30. Евгений Грибков (1СERP) 996 13.06.17 12:29 Сейчас в теме
(20)
Так одной из ключевых проблем этого проекта было то, что границы определила ИТ-служба. Границы были. Позже оказалось, что то, что получалось "в границах" бизнесу было не нужно.
31. Евгений Грибков (1СERP) 996 13.06.17 12:30 Сейчас в теме
(21)
Выше был положительный отзыв о картинках. Так что пока 1:1
32. Brr (brr) 178 13.06.17 13:22 Сейчас в теме
В первый же день прилетела вторая «атомная бомба»: как оказалось, выделенные в апреле ключевые пользователи тоже не владели полной информацией: были люди (а иногда и целые отделы), которые работали «чуть-чуть по-другому».


Это классика внедрения, при опросе руководителей и исполнителей, какие функции выполняют исполнители, списки функций не совпадают :)
1СERP; sunrise2506; +2 Ответить 2
33. Роман Солодовников (solodovnikov.84) 4 13.06.17 20:52 Сейчас в теме
Как часто такое приходиться встречать.Хуже наверное только бывает,когда твой руководитель согласовывает то,что сам не понимает.Или оценку делает.Или когда желания клиента многократно превосходит его финансовые возможности.А сейчас стало модно играть конкурсы.Где ТЗ от клиента его желаний это бред сумасшедшего. Или проще,копирование описаний конфигураций с сайта 1с.А когда выигрываешь.Начинаешь разбираться,а оказывается нужно совсем другое.И намного дороже.Клиент в 99% сам не знает до конца,что он хочет.И после такого работать не хочется.Чувствуешь себя идиотом.Что скажешь "что в ТЗ то и сделаю?".После этого тебе точно спасибо не скажут.Порой,что бы что то внедрить уходит несколько недель понятия учета и принципа работы организации.В этом плане работы по 1с по мне так очень сильно спешат.Всегда очень маленькие сроки.После последней оценки переноса из сторонней программы в 1с моим руководителем при которой я пол месяца проработал бесплатно.Спасая честь нашей организация.Потому что он ее даже не открыл.Я ушел.Честно говоря,учет и программы становятся сложнее и работы,которые требуются от компаний франч стали дороже.Сейчас проще держать своего под боком.Сидел бы он в организации и пилил бы код.А не бежал бы после обеда ко второму клиенту.Статья действительно полезная.Приятно понимать,что не только ты один в таком бывал.Самое главное опыт чужой.Лишний раз убеждаешься.Что перед работой,нужно пройтись по всем пунктам,людям и задачам.Так что спасибо!
Gluk_1C; Dementor; rovenko.n; 1СERP; +4 Ответить 1
34. Aleksey Pirozhnikov (Samson-lim) 13.06.17 20:52 Сейчас в теме
Пару приемов на данную тему: Все из опыта.

Описание предметной области:
Проекты от 1000 часов и выше.
Внедрение типовых продуктов с доработкой. Считаю, что разработка с "0" - отдельная тема в ней не разбираюсь.
Говорю на своем опыте.
Ни с кем не спорю.

Команда проекта:
============================================================­=
1. Обязательно: РП Заказчика и РП Исполнителя. По договору РП Исполнителя должен быть главным (даже если в жизни не получится)
2. Обязательно: Кураторство проекта со стороны ТОП-менеджмента компании Заказчика. Кураторы в проекте участие принимать не будут, но туда мы будем бегать жаловаться и запихивать наши бумажки.
3. Обязательно: РП Заказчика не может являться программистом 1С. Он такая же рабочая лошадка РП со стороны Исполнителя. Он управляется ранее подписанными им бумажками. Я предпочитаю с ними дружить.
4. Обязательно: РП Заказчика должен быть функциональным заказчиком - чем выше тем лучше.
5. РП Исполнителя работает с бумажками и деньгами. Если он является хорошим коммуникатором (его все понимают), то еще отвечает за этот аспект. Не более. Архитектура - к архитектору, методология - к методисту. РП не использовать вообще, ни при каких обстоятельствах. РП согласовывает решения и бюджеты.
6. Обязательно: Кураторы со стороны Исполнителя, туда мы идем для того, что бы РП проверили по перечню подготовленных документов. И принесенных денег.


Техническое задание
============================================================­=
Исхожу из принципа, что детальное техническое задание на систему типа ERP/УПП/ Управление холдингом или более менее крупную УТ - физически не возможно (Из этого правила нет исключений в моем опыте)

Видел большое количество ТЗ и своих и очень крупных 1С франчайзи и SAP и Nav, короче вне зависимости от продукта или компании). Красивые документы делать делают, но в лучшем случае там только концепты решений. Концепты нужны обязательны. Лучше если Ваши сотрудники внутри проектной команды будут общаться через бумажку в виде конецпта.

Поэтому с рамками работаю так:
1. Рамки договора - в нем детальное блоки / и насколько возможно детальные функциональные рамки (названия функций).
2. Блоки как можно меньше, но не менее 100 000 - 150 000 рублей.

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

Демонстрации проводим сначала внутри проектной команды (ключевые пользователи, РП со стороны заказчика), потом включая пользователей на местах:
1. Начинаем с перечня в договоре: Перечень внедряемых блоков -> Перечень внедряемых функций. Перечень функций постоянно уточняем. Его я расширяю почти без ограничений (кроме ситуаций с интеграциями). Ни в коем случае не добавляем блоки. Добавление происходит только через изменение рамок договора и дополнительный бюджет. При этом нужно выделять найденные функции в отдельные блоки, информировать Заказчика об их появлении, но добавлять в проект, как писал выше, через договор.
2. Демонстрация типового функционала по перечню внедряемых блоков по перечню внедряемых функций.
3. Протоколы демонстраций и протоколы замечаний к демонстрации. Протокол демонстрации нужен для того, что бы написать что Вы показывали клиенту. А протокол замечаний, что бы он написал, с чем он не согласен. Остальное принимается в Базе. Далее эти бумаги и используем в качестве ТЗ. Можем оформлять, если требуется.
4. Устранение замечаний по протоколу замечаний к демонстрации (тут много вариаций, смотря как вы работаете с бюджетом)

Повторяем, пока всем не надоест.
=======================================

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

Опять цикл:
=========================================
1. Прогон внутри проектной команды (ключевые пользователи, РП со стороны заказчика)
2. Протокол замечаний к демонстрации
3. Устранение замечаний по протоколу замечаний к демонстрации (тут много вариаций, смотря как вы работаете с бюджетом)
4. Цель: Команда проекта со стороны заказчика должна наизусть знать этот пример, и официальный прогон должен стать "перерезанием красной ленточки".

Выход из цикла, когда всем надоест.
=======================================

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

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

Деньги:
=======================================
Деньги всегда вперед. К моменту передачи проекта заказчику 80% бюджета в деньгах должно быть у Вас.

Прочее:
=======================================
Желательно, что бы до момента, пока вы не получили с клиента 100% денег весь софт должен находиться на вашей территории, а лучше всего, что бы клиент и работал на Ваших серверах. Но это получается не всегда.
VladimirL; Vyatcheslav; корум; i_lo; Arrigo; Dementor; 1СERP; Светлый ум; solodovnikov.84; +9 Ответить
35. Антон Антонов (monkbest) 28 14.06.17 08:32 Сейчас в теме
Фига провальный проект :)
Единственный провал - отсутствие хорошего отзыва :)

Клиент все оплатил, включая переработки => прибыль получена. Для раздолья проект успешный, УПП втюхано, доход получен. Если бы было озвучено, что мы отработали 2000 часов, а нам заплатили за 1000, то да, грусть тоска.
Lacrimosa0000; Hans; artfa; rovenko.n; +4 Ответить 2
36. Зу Темирова (Zabava_) 9 14.06.17 08:50 Сейчас в теме
(32) увы, зачастую даже то что "говорят" исполнители и то что они "делают" на самом деле, тоже не совпадает. На моей практике они "забывают" о чем-то сообщить, нередко это ключевая их функция с точки зрения автоматизации.
37. Миколка Ровенко (rovenko.n) 14.06.17 09:27 Сейчас в теме
(32)Согласен, на практике была ситуация, когда неделю прописывали схемы процессов с руководством, а потом пришел работник, который будет работать с этой системой. И сказал, что он физически не успеет всё делать, потому что при текущей нагрузке он выдает печатные документы работникам в течение двух часов (а надо за полчаса), а при доработке количество кликов увеличивается больше чем в два раза.
38. Миколка Ровенко (rovenko.n) 14.06.17 09:32 Сейчас в теме
(36)Требуйте подписания ТЗ не только руководителями, но и участниками рабочих групп. Когда будущие пользователи видят, что под документом будет стоять ИХ подпись, сразу же начинают вспоминать больше, начинают вчитываться в ТЗ и давать комментарии (и количество неучтенных моментов сильно уменьшается).
1cmax; АльфаАвтоПрограммист; 1СERP; +3 Ответить 2
39. 1ckun (smirnov.es) 14.06.17 09:55 Сейчас в теме
(22) Кстати да, руководителю департамента-заказчика, или ИТ-службы, всегда в разы проще выбить большой бюджет на подрядчика, чем на небольшое увеличение ФОТ для внутренних исполнителей. Много раз сталкивался с этим
40. Николай Переляев (nickperel) 1 14.06.17 11:03 Сейчас в теме
(17)
О как! По жизни, я так понимаю, если бы 20% бюджета заплатили упомянутым двум толковым сотрудникам ИТ, проект был бы не провальным, а вполне себе успешным. Это, собственно, иллюстрация к моему несостоявшемуся докладу на конференции Инфостарта. Причина провальных проектов (ну, процентов на 60) - привлечение "профессиональных" внедренцев.


В статье описано, что ИТ - отдел молотил на 100500 процентов. Не помогло.
"Профессиональных" - имеется в виду, тех что соглашается по всем позициям с заказчиком и тонет в компромиссах? Или не выполняет обязательства? На что намек?
Что проект с ERP скорее всего не случиться, если привлечь кого-то со стороны? Это не так.
41. Brr (brr) 178 14.06.17 11:15 Сейчас в теме
(36) Согласен, опрос это только первый этап. Потом еще и собственное исследование бизнес- процессов нужно делать.
42. Евгений Грибков (1СERP) 996 14.06.17 11:24 Сейчас в теме
(35)
Ну... перерасход бюджета там был приличный. Клиент остался недовольный. Это и есть неспешный проект.
43. Николай Переляев (nickperel) 1 14.06.17 11:41 Сейчас в теме
(33)
Как часто такое приходиться встречать.Хуже наверное только бывает,когда твой руководитель согласовывает то,что сам не понимает.


Такое с обеих сторон. Что у такого руководителя в отделе на фикси, что у такого франча ничего не сделаешь, не сдашь и не заработаешь. Хоть и говорят о полезности компромиссов, но работать бесплатно не допустимо.
44. Николай Переляев (nickperel) 1 14.06.17 11:49 Сейчас в теме
(35)
УПП втюхано, доход получен.

Деньги идут от живущего проекта, а не коробки. Втюхивать надо лабутены дамам. Это продуктивнее.
45. Николай Переляев (nickperel) 1 14.06.17 11:52 Сейчас в теме
(41)
собственное исследование бизнес- процессов

а если это производство, то ВНЕЗАПНО придется составить представление о технологии и предметной области.
46. Роман Иванов (АльфаАвтоПрограммист) 14.06.17 13:32 Сейчас в теме
Статья отличная! Спасибо автору и особо организатору статьи, как понимаю, Евгению Грибкову.
Далее по порядку:
1. Небольшое замечание, больше из внимания к деталям (ну то есть вредности))): введите стандарт на проверку и корректировку статьи)) проскакивают опечатки, например: "у них понималась только" - "понималось" все-таки наверное, "во-первых, во время признавать" - "вовремя".
2. Картинки: картинки оставить! Вообще рулят, особенно с зюзьгой!))
3. Вопросы:
3.1 Как читается из статьи, это было проектное внедрение, т.е. полностью всего и сразу и конечно на УПП? Почему не попробовали идею с пошаговой автоматизацией, например, тех же продажников автоматизировать на УТ11?
3.2 Функциональная модель вообще была сделана изначально без интервьюирования пользователей??? Если да, то вы конечно смертнички еще те...
3.3 И к работе программистов: это как так появлялись одинаковые по смыслу реквизиты от разных программистов? То есть даже справочники не были проработаны/согласованы?
Вопросы конечно, еще есть, но эти появились сходу.
И в качестве финального комментария: согласен с одним из предыдущих ораторов:
Если за проект получены деньги и закрыты акты, то проект является неудачным только для одной стороны, если наоборот - то для другой. Только сожаление от неудачной совместной работы всегда взаимно.
47. Зу Темирова (Zabava_) 9 14.06.17 13:53 Сейчас в теме
(38) требовала, обвинили в бюрократии :)
Требовала и когда работала со стороны ИТ заказчика и много позже, когда стала работать на стороне исполнителя. Помогает конечно, но не панацея.

По моему опыту залог успешного внедрения это вовлеченный ответственный пользователь и вовлеченный же представитель заказчика (руководитель) с административным ресурсом. С этой парой можно горы перевернуть. Даже преодолеть молчаливое сопротивление ИТ службы заказчика. Отсутствие заинтересованности одного из них сильно усложняет процесс внедрения, а обоих делает его заведомо неудачным. Для меня самый провальный был проект в котором внедрили, работало, приняли, но продолжили работать в ексель... "потому что привыкли и так проще". Внедряли Документооборот Корп.
1cmax; 1СERP; +2 Ответить 3
48. Миколка Ровенко (rovenko.n) 14.06.17 15:24 Сейчас в теме
(47)"потому что так привычнее" - и не говорите, часто бывает. Внедрили на предприятии автоматизированную систему, но сотрудники "старой закалки" продолжают писать проводки вручную на бумаге карандашиком.
Просто РП должен изначально указать, что подписывать ТЗ должны его потребители. А потребителем выступает будущий пользователь, а не руководитель Заказчика. Руководителю абсолютно неважно какие кнопочки будут на формочках и документах.
49. friend0 14.06.17 16:07 Сейчас в теме
Доводилось только участвовать в проекте по переходу с переписанной семерки на УТ 10.3 будучи недавно взятым в штат. С одной стороны это немного похоже на франчей полной неосведомленностью о процессах в конторе, с другой возможностью неофициального общения с пользователями т.к. все же "свой". Ну и вообще подход не срубить бабла за подписанное ТЗ, а внедрить в срок с максимальной работоспособностью ибо еще тут работать (или не работать, если завалить).

Из того что вынес (не считая банального саботажа, "невозможно работать", "верните старую базу") :
- Начальство страшно далеко от народа. Опрос начальника отдела о работе внутри может дать 20% информации, из которой половина не будет соответствовать действительности.
- Каждый юзер знает только свои "кнопки" и может рассказать/вспомнить о половине из них. Процентов 10 из того что юзер делает он делает "неправильно", еще процентов 20 имеющегося нужного для него функционала он не знает.
- Программист, который правил семерку уже забыл 80% того что делал и как вообще все функционирует
- Из функционала без которого "нельзя жить прямо совсем никак": 30% не используется вообще, еще 30% можно убедить по-другому делать штатными средствами, а 20% отложить на "прекрасное далёко" после запуска. Но это не значит, что меньше надо дорабатывать, т.к. при попытке эксплуатации всплывет еще в два раза больше реально нужного функционала.
- Ключевые пользователи, это не те кто больше всех кричит и не начальство. Это те кто бьет больше всех данных. В обычной жизни на них особо никто не обращает внимание, но если из-за внедрения их работа замедлится на 10% - можно считать проект заваленным. Начальство же сможет пережить отсутствие "жизненно важного" отчета неделю-другую.
- Наверняка есть пользователи про существование которых все забыли. Например, какой-нибудь бухгалтер, который обработкой тягает данные в бухгалтерию и не задумывается откуда они берутся.
- Вообще неплохо пособирать статистику в старой базе, что чаще всего используется и кем.
- Нужно как можно раньше давать(заставлять) пользователям заводить документы в новой базе дублируя рабочие, чтобы всплывал необходимый функционал. Ну и вообще чтоб привыкали постепенно.
- Некоторые процессы юзеры не могут объяснить так, чтоб их можно было правильно понять. Лучше все по десять раз переспрашивать и быть готовым к тому, что понял все неправильно.
- Одни и те же термины разные юзеры могут использовать в совершенно разных значениях. Надо сразу держать в уме вариант, что если как-то в голове совсем не укладывается о чем они все говорят, то возможно они говорят совсем о разных вещах и не надо их соединять воедино. Неплохо завести словарь терминов в привязке к пользователям, чтобы не путаться.
- Главное - это общение. Одна и та же конфигурация может быть воспринята и как "в принципе можно и так начать работать, а потом допилите" и как "вообще невозможно работать, откатывайте взад и прощайте".

П.С. результат внедрения был так же полунеуспешен. Первый запуск провалился и пришлось запускаться на пару недель позже (тоже профукали "окно" как ОП). Матюки, ругань, круглосуточная работа и прочие радости. Но в итоге запустились с горем пополам. Я остался, начальник - нет.
VladimirL; monkbest; Leja; Crazy_kz; корум; katenok86; АльфаАвтоПрограммист; i_lo; Gluk_1C; Dementor; KapasMordorov; +11 Ответить 2
50. Евгений Грибков (1СERP) 996 14.06.17 16:20 Сейчас в теме
(49)
неправильно

Очень интересно!
51. Vera 1 (VeraPikuren) 15.06.17 09:05 Сейчас в теме
(46) Пикурен Вера:
3.2 Функциональная модель вообще была сделана изначально без интервьюирования пользователей??? Если да, то вы конечно смертнички еще те...
//Конечно, ФМ была именно с пользователями - и интервью, и попытка демонстрации - все как положено.
3.3 И к работе программистов: это как так появлялись одинаковые по смыслу реквизиты от разных программистов? То есть даже справочники не были проработаны/согласованы?
//Я же писала про "кровавые слезы" :)
52. Зу Темирова (Zabava_) 9 15.06.17 09:19 Сейчас в теме
(49) по поводу юзеров зачастую так и есть :) Но! Каждый проект это уникальный случай. Проект о котором я писала выше для меня был необычен тем, что именно руководитель понимал все процессы до мелочей и описывал их. А пользователи вообще не вникали в суть процесса. Только рассматривали очень узко свой участок. Когда я обнаружила что через три месяца после начала использования Документооборота все еще ведется и постоянно актуализируется экселевский список дней рождений сотрудников и ключевых контрагентов я опустила руки. На вопрос зачем, ведь в системе уже все заведено, и актуализируется, сотрудники принимаются и увольняются, она ответила мне так проще. И я бы поняла, если бы человеку было трудно работать с программами в силу возраста (есть такой стереотип, что пенсионерам компьютер не одолеть), но нет, ей не было еще и тридцати и прекрасно она всем владела. Не было главного, желания. И я оказалась бессильна.
И ощущения остались странные, вроде внедрили, вроде работают, но как-то сложно очень и кажется не стало легче, стало больше работы. Это как купить машину представительского класса и возить на ней дрова с дальнего угла двора к дому. А на работу за сто километров ездить на велосипеде, потому что так привычнее.
АльфаАвтоПрограммист; Dementor; rovenko.n; +3 Ответить
53. Антон Антонов (monkbest) 28 15.06.17 12:59 Сейчас в теме
(42) из статьи следует, что недовольство было из-за увеличения сроков и бюджета, а также из-за обманутых ожиданий от внедрения. Т.е. не внедренец пострадал, получив первоначально оговоренные деньги и потратив больше часов, а заказчик, оплатив изначально оговоренное и дополнительные работы.
У меня было несколько опытов перерасхода, но пострадал исполнитель (я), не получив прибыль с проекта. А вот заказчик был доволен, хоть и были сорваны все сроки, он получил систему удовлетворяющую ожидания.

Тут, как и почти всегда, проблема в продажниках, продавших не то не туда. А дальше у каждого своя дорожка:
1. отменить проект и разбежаться с минимальными потерями, сразу как только пришло понимание, что мы занимаемся чем-то не тем. (все расстроились)
2. внедрять до победного, за оговоренные ранее деньги (заказчик рад, исполнитель расстроился)
3. внедрять ровно то, что оговорили согласно ТЗ и трясти деньги на допы (заказчик расстроился, мы рады, но делаем вид, что расстроились)
54. Антон Антонов (monkbest) 28 15.06.17 13:03 Сейчас в теме
(44) стоимость УПП не маленькая, а маржа франча примерно половина. в зависимости от статуса. Плюс есть такая штука как показатели работы, которые надо выполнять, чтобы быть центром компетенции по производству надо было вывешивать на сайте как много УПП мы внедрили, причем в терминах 1С продажа + бумажка с отзывом = внедрение.
Т.е. стоит у Вас задача стать ЦКП и Вы ориентируете своих продажников на втюхивание УПП, а не УТ, которое как писала девушка было бы логичнее.
55. Александр Рытов (Арчибальд) 2659 15.06.17 19:39 Сейчас в теме
(22) Знаю, сам боролся. Но полляма обещали. Правда, заплатили все же 0.4
56. Симон хачатрян (hacsi) 16.06.17 13:35 Сейчас в теме
Друзья,
примените технологию Scrum!
.
57. Николай Переляев (nickperel) 1 19.06.17 09:59 Сейчас в теме
(54)
+ бумажка с отзывом = внедрение.
Т.е. стоит у Вас задача стать ЦКП и Вы ориентируете своих продажников на втюхивание УПП, а не УТ, которое как писала девушка было бы логичнее.


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

А "втюхать", еще раз, не получиться у вас ничего. ЦКП или не ЦКП, без разницы. Что УТ, что УПП потом надо внедрять. Иногда это сложно. Вот про это этот тред.

И да, я часто, бывает слышу критиков вроде вас, которые комментируют посторонние им проекты в определениях "они втюхать хотят". Это как минимум безответственно, потому что заочно. Как минимум..

После рекомендаций иксперта вроде вас, иногда остаются конторы, например, с УТ и десятком баз БП. Попытка потом собрать общую упраленческую\неуправленческую отчетность сколько будет стоить? Объединение справочников? Не 150 тысяч, примерно на круг? И без разницы есть или нет производство.

А сколько стоит УПП в случае УТ + 10 х БП уже без разницы. Здравый смысл проехали на прошлой станции. "Маржа франча" - не то же что и бонус с продаж менеджера.

И да, 1С собирает "бумажки" о продажах, которые внедрения. И о внедрениях, которые продажа. А что их не надо собирать? И за всей информацией покупателя адресовать в трэды на мисте?
Правильно, нет?
Gluk_1C; Dementor; rovenko.n; +3 Ответить 1
58. Николай Переляев (nickperel) 1 19.06.17 10:13 Сейчас в теме
(55)
Знаю, сам боролся. Но полляма обещали. Правда, заплатили все же 0.4


Я все время пытаюсь это предлагать заказчику. Когда получается, все идет очень энергично.
У вас получилось с внедрением?
59. Николай Переляев (nickperel) 1 19.06.17 10:29 Сейчас в теме
(38)
Требуйте подписания ТЗ не только руководителями, но и участниками рабочих групп. Когда будущие пользователи видят, что под документом будет стоять ИХ подпись


Сценарий - они отказались, директор не настаивает и сам все подписал. Предложил не приставать к его людям и начинать уже работать. Людей указал, доп. оплату им зарубил, от основных обязанностей не освободил даже частично.
И как? Отказаться от проекта, если он сложный?
60. Николай Переляев (nickperel) 1 19.06.17 10:44 Сейчас в теме
(47)
Для меня самый провальный был проект в котором внедрили, работало, приняли, но продолжили работать в ексель... "потому что привыкли и так проще". Внедряли Документооборот Корп.

С любым документоводом так, не только с 1с. Лечится только принудительно - административной загрузкой всех файлов в инф.базу и почтовыми учетками. Потом бакап и закрытие шары "Общая папка".
Причем грузить надо все, включая mp3 и джипеги с корпоративов. Только сами владельцы файлов могут что-то там рассортировать.
61. Николай Переляев (nickperel) 1 19.06.17 10:46 Сейчас в теме
(48)
Руководителю абсолютно неважно какие кнопочки

Важно ему это. Ему нужно, чтобы те что с карандашиком и проводками сообщили ему, что они теперь пишут проводки в программе.
62. Миколка Ровенко (rovenko.n) 19.06.17 10:46 Сейчас в теме
(59)
- они отказались, директор не настаивает и сам все подписал. Предложил не приставать к его людям и начинать уж

Неправильный директор. Дело не в отказе от проекта. Просто это один из самых больших "рисков", который потом обязательно вылезет боком.
63. Николай Переляев (nickperel) 1 19.06.17 10:52 Сейчас в теме
(62)
Неправильный директор. Дело не в отказе от проекта. Просто это один из самых больших "рисков", который потом обязательно вылезет боком.

Все директора так или иначе "неправильные". У "правильных", как правило, все и так работает.

Тут даже не риск. Нельзя работать без принятых результатов, будет платежный дефолт. А работать надо, вот и пишем ноу-хавы.
64. Зу Темирова (Zabava_) 9 19.06.17 10:53 Сейчас в теме
(53) возможно, не могу сказать за автора. Но я увидела немного другое. В такой ситуации страдают все и внедренец и заказчик. Не все же меряется полученной прибылью и произведенными расходами. Я вижу недовольство собой, признание того, что неправильно оценила ситуацию. Да. согласна, очень часто продажники продают не то и не тем, но ведь когда я прихожу на проект, я должна его оценить на жизнеспособность. Увидеть и предотвратить какие-то проблемы. Естественно не все, но уж точно больше, чем может увидеть продажник. И вот тогда, на начальном этапе, проговорить эти проблемы и может даже прервать проект. Мне кажется это немного об этом.
Очень уважаю автора за мужество признаться в своих ошибках, в первую очередь себе. На мой взгляд, это очень ценно. И уж в вдвойне - признаться публично.
Спасибо автору, что поделились таким опытом.
65. Зу Темирова (Zabava_) 9 19.06.17 11:02 Сейчас в теме
(60)у меня было острое желание снести эксель :)
66. Евгений Заручейский (zarucheisky) 19.06.17 11:11 Сейчас в теме
(25) Технологических преимуществ от перехода нет.
На 77 используя 1С++ и прямой доступ к данным можно перемалывать огромные объемы, да и просто вынести расчет за пределы транзакции - и вуаля, получите вертолет.
67. Миколка Ровенко (rovenko.n) 19.06.17 11:25 Сейчас в теме
(61)нет, нет. Не путайте, руководителю важен результат - отчет по закупкам/ продажам, бюджеты, проводки и прочее. Всякие "создать на основании", "заполнить по данным", галочки руководителю глубоко безразличны. Ему эти удобства ни к чему.
68. Миколка Ровенко (rovenko.n) 19.06.17 11:26 Сейчас в теме
(63)именно. пишем, а потом оттачиваем, хотя можно было написать с первого раза.
69. Евгений Грибков (1СERP) 996 19.06.17 14:27 Сейчас в теме
(53)
Не совсем понял. Внедренец пострадал, потому что получил убыток из-за значительного увеличения объема работ от запланированного. Заказчик пострадал, потому что получил не до конца то, что хотел. И в какой-то момент все поняли, что продолжать дальше мучать друг друга (нам "мочить" заказчика ссылками на ТЗ, а Заказчику "мочить" нас тем, что "ну, мы же так не можем работать") просто нет смысла. "Отменили проект и разбежались".
Т.е. в Ваше квалификации это частично пункт 1, частично пункт 2, частично пункт 3.
70. Евгений Грибков (1СERP) 996 19.06.17 14:29 Сейчас в теме
(54)
Вера писала, что логичнее было бы РАССМОТРЕТЬ УТ. Подошла ли она им в конечно итоге - тоже вопрос - регламентированный учет, расчет себестоимости и бюджетирование делали, на первый взгляд, УПП более приоритетным вариантом.
Но пробовать моделировать на УТ было нужно и сравнивать где объем доработок был бы больше и сложнее.
71. Евгений Грибков (1СERP) 996 19.06.17 14:30 Сейчас в теме
(56)
Расскажите об успешном опыте.
72. Евгений Грибков (1СERP) 996 19.06.17 14:51 Сейчас в теме
(64)
Я в 70-ом посте немного прокомментировал ситуацию.
73. Антон Антонов (monkbest) 28 20.06.17 08:05 Сейчас в теме
(57) мед, го*но и гвозди, всплеск эмоций. Откуда Вы взяли УТ + 10 БП, или ошиблись кому отвечали?
74. Леопольд Роскошный (ЛеваРоскошный) 32 20.06.17 16:33 Сейчас в теме
(66) а вот это, самое страшное бомба замедленного действия. .
в курсе, что на десятке 7.7 даже не запускается.?

там получится жуткая смесь бульдога с носорогом, продет еще 3-4 года обновится SQL и перестанет работать 1с++. ну или еще стонить.
там кстати ограничение на 32 а 64 уже во всю.
костыли страшные, сталкивался с таким.
эра 7,7 прошла она была прекрасна, но она прошла. увы.

Есть в сети статья человека который переводил с статического HTML на динамические рельсы.
чем больше тянешь, тем сложнее можно вообще бизнес потерять.
75. sssssssssssssss sssssssssssssss (sssss_aaaaa_2011) 20.06.17 17:03 Сейчас в теме
(74)
в курсе, что на десятке 7.7 даже не запускается.?
Не-а! У меня на 64-битной запускается. ЧЯДНТ?
Gluk_1C; monkbest; +2 Ответить 2
76. Леопольд Роскошный (ЛеваРоскошный) 32 20.06.17 17:38 Сейчас в теме
(75) я имел ввиду установщик.
ну да с бубном и еще чем-то можно пустить но это уже изврат.
77. Вася Пупкин (w.r.) 29 21.06.17 08:28 Сейчас в теме
Когда читаешь фразы типа "кодирование", "куски кода" - очень сильно удивляешься. 1С ники очень хотят мнить себя ИТ-профессионалами, а на самом деле они даже не ИТ-любители. Многие, так называемые "программисты", даже "не ведают, что творят"
78. Дмитрий К. (Dementor) 9 21.06.17 14:57 Сейчас в теме
(77) Судя по вопросам и ответам на стековерфлоу таковыми так же являются 90% якобы "программистов" на javascript, php, python и тем более на недоязыках типа bash и lua :)

Не говоря о том, что многие сисадмины из крутых западных контор на огромных окладах даже не дотягивают до уровня "любителей". Как свежий пример - инцидент с GitLab.com

Все эти крутые западные ИТшники, которые не вылазят с митапов и конференций, даже в подметки не годятся среднестатистическому 1С-программисту Васе, который настраивает политики AD, оптимизирует работу СУБД, обновляет платформу и конфигурации своих пользователей, отвечает за работоспособность корпоративного сайта (покупка и продление доменного имени, получение сертификатов, обновление сайтов от известных уязвимостей и так далее), публикует веб-доступ в базы для внешних пользователей и для сотрудников с мобильными приложениями, ведет учет выданных сотрудникам мобильных устройств и обновляет на них программы для 1С (всякие мониторы показателей, терминалы для кладовщиков, УНФ, Агент+, Моби-С и многие другие), настраивает и следит за работоспособностью подключенного оборудования, вытирает сопли за многочисленным группами пользователей, которые не могут внести проводки/остатки/лидов, ищет причины кривых данных, пишет сотни пользовательских инструкций, а так же ТЗ для наемных франчей/фрилансеров, когда руководство решает переходить на новую систему. А еще этот Вася умеет программировать! :))

P.S. Шутки шутками, но не нужно недооценивать доступные трудовые ресурсы. Не каждому быть экспертом по технологическим вопросам, а вот монотонной работы по настройке форм и клепанию отчетиков на каждом внедрении всегда выше крыши; эту работу должен кто-то делать, ведь без нее даже при идеальной архитектуре конечные пользователи будут воротить носом и говорить о криворуких внедренцах.
1cmax; Gluk_1C; monkbest; denker; +4 Ответить 1
79. Николай Переляев (nickperel) 1 21.06.17 18:03 Сейчас в теме
(67)
нет, нет. Не путайте, руководителю важен результат

Где я путаю? Написал - директор проверит информацию у своих.
Они скажут ему буквально - "стало невозможно работать, это какой-то кошмар.." и вы тоже начнете думать "про галочки".
80. Николай Переляев (nickperel) 1 21.06.17 18:06 Сейчас в теме
(66)
Технологических преимуществ от перехода нет.
На 77 используя 1С++ и прямой доступ к данным можно перемалывать огромные объемы

Просто интересно, вы их наверно и в самом деле перемалываете. Если да, то сколько уже лет точите эту связку 7.7+1С++?
10 лет есть уже? Все туже самую инфобазу или разные?
81. Николай Переляев (nickperel) 1 21.06.17 18:08 Сейчас в теме
(71)
Расскажите об успешном опыте.

Не расскажет :-)
82. Николай Переляев (nickperel) 1 21.06.17 18:12 Сейчас в теме
(73)
Вы в очередной раз лепите старую тему про "втюхать". Что, типа, надо УТ вместо УПП поставить и жить без проблем.
Старая лажа.
83. Николай Переляев (nickperel) 1 21.06.17 18:13 Сейчас в теме
(75)
в курсе, что на десятке 7.7 даже не запускается.?
Не-а! У меня на 64-битной запускается. ЧЯДНТ?


И на 10-ке запускается и работает под 64-битной ос, но не перестает быть 32-х битной
Gluk_1C; ЛеваРоскошный; +2 Ответить
84. Николай Переляев (nickperel) 1 21.06.17 18:16 Сейчас в теме
(77)
(77)
Когда читаешь фразы типа "кодирование", "куски кода" - очень сильно удивляешься. 1С ники очень хотят мнить себя ИТ-профессионалами, а на самом деле они даже не ИТ-любители. Многие, так называемые "программисты", даже "не ведают, что творят"


Потому, что у тебя ничего не спрашивают. Расскажи немедленно как надо, чтобы прозрели и перестали "мнить"
85. Антон Антонов (monkbest) 28 22.06.17 07:06 Сейчас в теме
(77)
Когда читаешь фразы типа "кодирование", "куски кода" - очень сильно удивляешься. 1С ники очень хотят мнить себя ИТ-профессионалами, а на самом деле они даже не ИТ-любители. Многие, так называемые "программисты", даже "не ведают, что творят"


Недопрограммисты сайтоделатели сюда не ходят -> жирный троль обнаружен :)
86. Вася Пупкин (w.r.) 29 22.06.17 07:11 Сейчас в теме
(78) соглашусь. Повидал я экспертов в "белых перчатках". Исключительно неприятные ощущения от общения
87. Антон Антонов (monkbest) 28 22.06.17 07:31 Сейчас в теме
(80)

На самом деле Вы недооцениваете ценность баз на 7.7 для бизнеса. Дело тут не в технологиях. Бух и ЗиК давно переехали на 8 из-за регламентированной отчетности. В основном живы Торговли и Склад и Комплексные сильно перепаханные. Они настолько заточены под процессы контор, в них столько вложено труда программиста и руководителей. В них идеальная автоматизация всех внутренних процессов. С ними жалко расставаться, получить современный аналог, столь же вылизанный и допиленный стоит очень больших денег.
База на 7.7 скорее всего живет более 15 лет, это значит, что как минимум бизнес успешно пережил все эти 15 лет. Все 15 лет в эту базу вкладывались денежки. даже если бюджеты были маленькие, за 15 лет это уже огого. И руководство и персонал уже привыкли к определенному уровню автоматизации и сделать шаг назад к типовой 8 они не готовы, это потребует увеличения штата сотрудников, а вложиться разово в допиливание 8 до такого же уровня автоматизации и интеграции - дорого, возможно, бизнесу это критичная сумма.

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

Не подумайте, что я защитник 7.7, я люблю новые технологии и мне приятнее ковыряться в "Такси", чем в "старушке", но старость надо уважать
88. Антон Антонов (monkbest) 28 22.06.17 07:40 Сейчас в теме
(56)
Друзья,
примените технологию Scrum!
.


Колумб что ли?
Все уже в 1С знают эти чудные слова и применяют их на практике, но не все виды работ вписываются в scrum, проекты с фиксированной стоимостью как правило плохо ложаться в спринтовые процессы. Это все хорошо для почасовой оплаты и доработок уже работающих систем, каждую неделю согласовываем список работ, их оценку и погнали, в конце выдали результат, которым можно пользоваться. А на внедрении с нуля с фиксированным бюджетом такое управление неподходит.
89. Антон Антонов (monkbest) 28 22.06.17 08:09 Сейчас в теме
(82) В крупных франчах проблема втюхивания актуальна, т.к. они должны соответствовать политике верховного главнокомандующего. Сейчас в 2017ом всех напрягают втюхивать "сервисы", например. Были времена УПП, ERP, ИТС... всегда есть тренд навязанный сверху и это бывает минусом
90. Леопольд Роскошный (ЛеваРоскошный) 32 22.06.17 10:05 Сейчас в теме
(87) но старость надо уважать
безусловно уважать и на пенсию провожать.

мне тур рассказали что была на одном предприятии 7,7, всем нравилась, но пришло время обмениваться инфой (или интегрироваться куда-то), а все 7.7 не поддерживает и все.. потеряли контракт.
91. Юрий Наливко (Gluk_1C) 22.06.17 10:30 Сейчас в теме
(90) у подруги сестры ее мужа друга..... можно больше конкретики?
92. Николай Переляев (nickperel) 1 22.06.17 10:41 Сейчас в теме
(89)
Сейчас в 2017ом всех напрягают втюхивать "сервисы", например. Были времена УПП, ERP, ИТС... всегда есть тренд навязанный сверху


Снова "втюхивать". Да ты упорный. Или упоротый.
Это называется механизм франшизы 1С. Никто никому ее, франшизу, не навязывает. Так же никто не навязывает работать во франшизе.
И вообще никто никого не заставляет использовать 1С.

И не надо ничего пояснять, вы видимо не при делах.
93. Антон Антонов (monkbest) 28 22.06.17 14:18 Сейчас в теме
(92) я -
упоротый.

никто не навязывает, ок.

Ты хоть на партнерские семинары ходил? Умный :)
94. Антон Антонов (monkbest) 28 22.06.17 14:20 Сейчас в теме
(90) если речь о готовой интеграции с чем-то, то да функционал УТ шире. А по технологиям в 7.7 все есть, вопрос только найти разработчика "старичка" с руками - это сложнее год от года
95. Леопольд Роскошный (ЛеваРоскошный) 32 22.06.17 14:54 Сейчас в теме
(94) если это ларек с шавермой или цветочный да без проблем можно 6.0 вкорячить.

(91) вкраце столовка была на заводе, кормила работяг , руководство завода решило компенсировать работягам еду.
надо было ПО столовки съинтергрировать с Заводским ЗУП (причем стандатно по КД 3,0 так как модуль уже есть.).
и все столовку(подрядчика с 7.7) выгнали наняли другого подрядчика.
вот так вот древние технологии мешают бизнесу.
96. Антон Антонов (monkbest) 28 22.06.17 15:03 Сейчас в теме
(95) типовой общепит 7.7 заменили на типовой общепит 8, удивили, делов на 5 минут :)
97. Леопольд Роскошный (ЛеваРоскошный) 32 22.06.17 15:22 Сейчас в теме
(96)


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

внедрить общепит за 5 минут?? обучить всех официантов, поваров-сметчиков ??? да вы Чак Норрис от 1с.
98. Юрий Наливко (Gluk_1C) 23.06.17 12:02 Сейчас в теме
(95) так а что мешало интегрировать не по КД 3?
ИМХО: Это не древние технологии, а формальный повод слезть с 7.7 и отказаться от подрядчика, мне думается все же написать обмен было дешевле чем внедрять "работающую" систему ))))
корум; 1cmax; +2 Ответить 1
99. Леопольд Роскошный (ЛеваРоскошный) 32 23.06.17 13:00 Сейчас в теме
(98) так а что мешало интегрировать не по КД 3

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

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