Перед вами человеческий лонгрид без капельки участия ИИ. Неприлизанный, с ошибками, нестыковками и потерей нити изложения. Ещё и про 1С.
Текст для меня необычный, потому что – конкретный. Ну, насколько тема управления проектами может быть конкретной. В статье изложен практический подход к выполнению проектов определённого, вполне конкретного типа.
Подход холиварный, не всем понравится, не всем подойдёт. Но проектов, выполненных по этому концепту, становится всё больше (да их и было много). А сейчас – становится всё больше, по совокупности причин.
Ну всё, переходим к делу. Итак, у нас УПП, и нам надо перейти на ЕРП – побыстрее и подешевле.
Концепт «Переезд»
Сразу говорю: я не противопоставляю разные концепции проектов внедрения ЕРП, не пытаюсь выявить лучшую, кого-то принизить или возвысить. Я лишь за то, что концепций – несколько, и каждая хороша в конкретной ситуации конкретного заказчика.
Попробую объяснить на контрасте. Обычный концепт для ЕРП – «внедрение». Применяется в нескольких случаях. Самый вот прям подходящий – когда у заказчика не было никакой автоматизированной системы (такое бывает, кстати, не удивляйтесь). Были эксельки, какая-нибудь Бухгалтерия предприятия для рег.учёта и ЗУП для зарплаты. В этом случае ЕРП внедряется почти с нуля – неоткуда перенести данные, не было автоматизированных процессов, отчётов и т.д. Поэтому надо обследовать все процессы, решать, что автоматизировать, как это сделать, причёсывать-нормализовать (или создавать с нуля) НСИ, разрабатывать всякие способы распределения расходов и т.д. Короче, делать проекцию реальных процессов на учётные с нуля.
Проекты по концепту «внедрение» обычно дорогие, т.к. требуют очень много работы аналитиков и консультантов – тех, кто процессы изучает, на ЕРП перекладывает, функциональные разрывы ищет, документацию пишет и т.д. По разным оценкам, от 50 до 80% стоимости проекта.
А теперь представим – у заказчика давно внедрена и успешно эксплуатируется УПП. Она всех устраивает, и решает все задачи, которые перед ней поставлены. Какие процессы хотели и могли автоматизировать – автоматизировали. Да, у большинства в 1С нет работающего производственного планирования – так его и в ЕРП не будет. Но в остальном УПП давно стала неотъемлемой, привычной частью бизнеса. И никто не собирался её менять, но…
Но поддержка УПП прекращается, и надо переходить в другую программу. Да, есть варианты оставить УПП, поставить рядом БП и ЗУП, сделать обмен и жить дальше. Нормальные варианты, но я их в данной статье не рассматриваю. Большинство выбирают ЕРП или КА2 (в контексте статьи считаем, что это почти одно и то же, и вся информация одинаково годится для обеих конфигураций).
Ещё раз акцентирую внимание: заказчики выбирают ЕРП не потому, что хотят, или она им нравится, или того требует развитие предприятия. У заказчиков просто нет выбора, они вынуждены перейти с УПП на что-то, и это что-то, как правило – ЕРП.
Так вот, это и есть переезд, как концепт проекта. Переехать из одной системы в другую, с минимальными затратами денег и нервов, без прироста функциональности, без красивых нормализаций, рефакторинга, пересмотра процессов и концепций. Просто переехать, пережить этот вынужденный проект и забыть о нём.
А уж потом, после переезда, что-то развивать в ЕРП, запускать новые для себя подсистемы, менять подходы к учёту затрат и т.д. Если будет потребность или лишние деньги. Обратите внимание – ровно то же можно было делать и с УПП, останься она на поддержке.
Ещё для ЕРП бывает концепт «перевнедрение», когда кто-то внедрил неправильно, ничего не работает, всё плохо и вообще. Зачастую внедрял сам заказчик, желая сэкономить, что-то пошло не так, а сил и желания довести до ума не хватило. Помучились и пошли к подрядчикам. Концепцию «перевнедрение» я привёл для разнообразия, чтобы рассматриваемый спектр вариантов был пошире 😊
Выбирайте тех, кто знает обе системы
Совет может показаться странным, но он сэкономит массу времени и денег. И не думайте, что подрядчик сам, по своей инициативе признается, что не знает УПП или ЕРП – задайте вопрос напрямую.
Если подрядчик не знает ЕРП, то тут вроде и обсуждать нечего 😊. Понятно, что речь идёт об относительном, а не абсолютном знании – никто не ведает всея ЕРП. Но основную функциональность знать всё-таки неплохо бы. Иначе заказчику придётся оплачивать её изучение. Оно не будет звучать, как изучение – есть хорошие слова «анализ» и «моделирование», под которые всё можно завернуть. Ещё раз акцентирую внимание: какие-то вещи – узкие, тонкие, глубокие – любой подрядчик будет изучать за деньги заказчика в ходе выполнения проекта. Но чем обучения меньше, тем проект дешевле.
Но в нашем случае, в обсуждаемом контексте, важнее знание предыдущей системы – УПП. И очень желательно знание не поверхностное, а хорошее, с большим опытом и сопровождения, и эксплуатации. Идеальное сочетание компетенций – когда человек работал с УПП и инхаус (на заводе), и от компании-агрегатора. Инхаус даёт глубину понимания и связь с бизнесом. Агрегатор даёт ширину опыта – человек видел УПП в компаниях разного типа, что даёт понимание разных вариантов её использования.
При переезде из УПП в ЕРП такие люди (знающие УПП) сэкономят огромное количество времени и денег, т.к. поймут процессы и доработки заказчика даже без его объяснений. Зачастую даже лучше, чем пользователи заказчика, которые работают с 2-3 документами/отчётами, могут показать что делают, но не понимают, частью какого процесса их действия являются.
Понимаю, что людей с хорошим опытом работы в УПП на рынке всё меньше, но они есть. Найдёте – сильно сэкономите. Иначе придётся платить аналитикам и программистам за изучение УПП.
Дорожная карта
Я слышал, что в «обычных проектах» (не переездах) составление дорожной карты – отдельная услуга, стоимость которой измеряется в миллионах рублей. Для обычных проектов это, зачастую, оправдано – если путь предстоит длинный, неизведанный, с множеством подводных течений и крутых поворотов.
Но у нас – переезд. Он делается или так, или эдак - вот и вся дорожная карта. От переезда к переезду путь немного меняется, но настолько незначительно, что за составление и корректировку дорожной карты деньги там брать стыдно.
Обследование процессов
Оно нужно, но в очень небольшом объёме. Обычно достаточно 1-2 дней. Собственно, за него и деньги-то можно не брать с заказчика.
Напомню, мы же переезд делаем. Что именно надо перевезти из УПП в ЕРП – нам известно. Точнее, для составления «списка вещей» достаточно провести 1-2 встречи с тем, кто знает почти всё. Лучшие кандидаты – ИТ-директор, или местный программист 1С, или главный бухгалтер, или финансовый директор бывает хорошо погружён. Короче, тот, кто в курсе большинства процессо��.
Чтобы была понятна разница с обычным обследованием, попробую объяснить. В обычном обследовании приходит аналитик от подрядчика, ему дают человека (например, из производства), и человек долго рассказывает аналитику, как у них протекает процесс со всеми составляющими, и как всё это отражается в системе. После чего аналитик ещё отдельно смотрит всё это в УПП (а если никогда не видел УПП – очень долго смотрит 😊). В обычном проекте всё это нужно посмотреть и узнать, т.к. цель – не перетащить учётный процесс из УПП в ЕРП, а автоматизировать живой процесс в ЕРП, не особо оглядываясь на то, как он жил в УПП. За эту работу аналитика надо заплатить – она довольно внушительная по времени.
В случае переезда мы видим, как протекает процесс, в самой УПП. Да, там не все детали видны – но на этапе обследования они и не нужны. Мы ведь перетаскиваем учётный процесс практически «как есть», т.к. он всех устраивает. С какими-то изменениями, понятно, но их будет не много.
Обследование чем-то похоже на оценку квартирного переезда – грузчики заходят в квартиру, смотрят, сколько вещей надо перетаскать, какие они по размеру/весу/сложности, есть ли рояль, большие зеркала и прочие негабариты, ну и т.д.
Если продолжать аналогию, то обследование в обычном проекте, выполняемому по концепту «внедрение» - это приглашение дизайнера в новую квартиру, чтобы он придумал ремонт, помог выбрать мебель, освещение и т.д. Всё новое, до последнего винтика.
Ну, вы поняли. У большинства процессов, документов, справочников, отчётов УПП есть аналоги в ЕРП. Список этих аналогов, и вариантов их использования, подрядчику известен. Перечень того, что плохо конвертируется при переходе – тоже (справочник Проекты, номенклатурные группы, счета в документах и т.д.).
Поэтому обследование процессов при переезде больше похоже на мэппинг (будь оно неладно, это слово) по известной таблице соответствия. Ну и некоторое количество творчества, обычно небольшое.
Не делайте нового
Ну, это понятно из концепта. Если у вас в УПП было только объёмно-календарное планирование продаж – в ЕРП его и запустите, не лезьте в цеховое планирование. Если у вас не было автоматизированного бюджетирования – пока и не будет. Не знали точно своих дефицитов – пока и не узнаете.
Точнее так: не делайте нового именно в рамках проекта. Иначе он перестанет быть переездом, и станет обычным внедрением. А значит – в разы дороже, дольше и нервнее.
Потом сделаете.
Обследование доработок
УПП крайне редко бывает без доработок. Если у заказчика такая – повезло, переезд обойдётся ещё дешевле. Но я буду рассматривать случай, когда доработки всё-таки имеются – в небольшом или среднем количестве. Понимаю, что оценки мои субъективны, но иначе вряд ли получится. Тут дело не только в количестве доработок, в смысле количестве строк кода, доработанных или добавленных объектов, но и в их структуре, сложности, изолированности. Бывает 10 строк кода, которые существенно меняют расчёт себестоимости, а бывает 5000 строк и 50 объектов, которые создают изолированный контур (вроде интеграции с СКУД), уже написаны на управляемых формах и перенести их в ЕРП – дело нескольких дней.
В среднем, по моему опыту, объём доработок всё-таки или небольшой, или средний. Из этого и буду исходить.
Так вот, обследование доработок в случае переезда – процесс несложный. Но, см. выше – нужен программист, который хорошо знает и УПП, и ЕРП. Он сравнит доработанную конфигурацию с типовой, увидит все доработки, по большей части из сам разберётся, зачем они нужны, что делают и есть ли у них аналог в ЕРП. А которые не поймёт – попросит объяснить.
Тут, правда, затык – очень часто у заказчика не находится людей, которые знают, когда и зачем была сделана доработка. Как ей пользоваться – знают. Зачем, почему – нет. И тут нам опять невероятно полезен опытный программист УПП – он поймёт назначение доработки с помощью реверс-инжиниринга.
По итогу программист составит перечень доработок, кратко изложит назначение каждой, есть ли типовой аналог в ЕРП (такое бывает), насколько сложно портировать доработку в ЕРП (бывает – легко, бывает – очень сложно и дорого). Далее все смотрят на этот список и принимают решения – что тащить с собой, что не стоит. Бывает такое – перенести доработку стоит дорого, а в УПП ей почти не пользовались. Чего на неё время и деньги тратить?
Что останется в списке – то попадает в состав работ проекта. Это надо будет доработать.
Отчеты и обработки
С отчётами и обработками какая обычно проблема в УПП: их дофигищща. За годы эксплуатации чего только не понаделали – и внешние печатные формы, и отчёты (непонятно кому нужные), бывает даже отдельный отчёт, который – просто вариант типового, и обработки заполнения.
Главная проблема всего этого – не понятно, что из этого используется, а что – нет. Если перед нами 10 объектов, выяснить можно и пешком – просто спросить. А если их 200 или 500? Можно, конечно, попробовать составить реестр, опросить пользователей, но… При запуске обязательно окажется, что перенесли то, что не нужно, и не перенесли то, что каждый день используется.
Так вот, я рекомендую простой технический приём – сделать следилку. Внешние отчёты и обработки вызываются из одного общего места, туда надо встроить сохранение информации о вызове и формировании – кто, когда и что выполнил или сформировал. Складывать данные в какой-нибудь регистр сведений. Это нужно всё быстренько сделать ещё на старте проекта, и оставить в покое на несколько месяцев.
Потом, ближе к запуску (месяца за 3, например), заглянуть – и реестр будет готов. Чем пользуются, кто, как часто. И всё, можно перетаскивать в ЕРП (искать аналоги, или адаптировать существующие отчёты и обработки).
Особенно это важно для печатных форм. Без отчётов и обработок люди пожить могут, а без оперативных бумажек – нет.
Не используйте ТЗ
Технические задания (ТЗ), частные технические задания (ЧТЗ), листы требований (ЛТ) и прочие подобные бумаги – штука полезная и нужная, но не в нашем случае. У ТЗ есть несколько назначений, но ключевое, именно в проектах – это фиксация договорённостей.
Если спросить заказчиков, что такое ТЗ и зачем оно нужно, то самый распространённый ответ – «это бумажка, которая нужна вам, программистам». Заказчики плохо понимают, что написано в ТЗ, потому что в момент, когда им надо это самое ТЗ подписывать, они ещё не видели новую систему. Ну и��и видели, но не работали в ней. Не знают, как там всё работает, и тем более – чего там не хватает, как это исправить, и поможет ли то, что написано в ТЗ, сделать систему лучше, а работу – проще.
И заказчик прав, говоря «ТЗ – это что-то для программистов». Точнее, это не для программистов, а для подрядчика, как юридического лица – это документ, на который потом можно ссылаться. Мы сделали то, что хотел заказчик – вот бумажка, всё написано-нарисовано, подпись стоит.
Второстепенное назначение ТЗ – передача информации от аналитика разработчику. Это мы тоже убираем в нашем случае – читайте ниже.
Итак, ТЗ – юридический документ, который страхует подрядчика. Заказчику пользы от документа – или никакой, или очень мало. А стоимость создания ТЗ на разработку вполне сравнима со стоимостью выполнения этой самой разработки. А иногда сделать ТЗ – дороже, чем саму разработку, т.к. в стоимость создания ТЗ включается не только его написание, но и предшествующий анализ (который делается именно «под ТЗ»), моделирование, рисование интерфейса и т.д.
Если переживаете, что без ТЗ кому-то из людей подрядчиков не будет понятно, что и как сделать – не переживайте, всё им понятно. А что будет не понятно – они всё равно спросят, независимо от наличия ТЗ.
Кстати, без ТЗ вопросов будет больше, они будут точнее и глубже – а нам это и нужно. Если есть хорошее ТЗ, понятное разработчику, он вообще вопросов не задаст – просто сделает то, что написано. А если написана была чушь?
И не забываем, что мы ведь переездом занимаемся, из одной системы в другую. Поэтому для большинства задач ТЗ буде�� одинаковое, по сути своей – «в старой системе была вот такая штука, нужен аналог в новой».
Собственно, на этом и приёмка строится. Заказчик сравнивает не с ТЗ, которого не понимает, а со старой системой, в которой проработал долго и плодотворно. Предваряя возражения подрядчиков о том, что «заказчик будет бесконечно менять требования» - не будет, см. ниже про отказ от фиксированной стоимости.
Отказ от фиксированной стоимости
Вопрос стоимости – скользкий и холиварный. Посему прошу сразу на меня не набрасываться – я лишь изложу одну из точек зрения, проверенную практикой. Предложенный подход годится не всем заказчикам и подрядчикам, не будет идеален для каждой ситуации. Но иногда он – само то.
Итак, наша цель – недорогой переезд.
Любая фиксация создаёт проблемы ближе к концу проекта. Упомянутое выше ТЗ – это фиксация требований. Я постарался достаточно подробно объяснить, к чему приводит фиксация. Неприятность её ещё и в том, что проблемы вылезают не сразу. В начале заказчик подписывает ТЗ, которого не понимает. Потом он даже принимает часть работ по этому ТЗ – всё или почти всё, что будет ему сдано до начала эксплуатации ЕРП. Потому что тоже не понимает – ему сдают работы на копии, на ограниченных тестовых данных. Заказчик говорит «ну, вроде то, что надо». А когда сам, своими руками, на живых данных, в реальных процессах начинает этим пользоваться – вот тут-то и вылезают реальные требования. Которые могут не совпадать с изначальными на 100 %.
А наша цель, напомню – недорогой переезд.
И что происходит дальше? Запуск системы или уже состоялся, или вот-вот случится. Времени на переделки уже нет. Денег (у подрядчика) – тоже. Подрядчик достаёт и показывает ТЗ. Специалисты заказчика гневно объясняют, как этим ТЗ воспользоваться. Идёт срач. Заканчивается он по-разному. Где-то заказчик подвинется, потому что ему надо запуститься. Где-то подрядчик поработает за свой счёт, т.к. ему важнее получить оставшиеся деньги. Иногда все встают в позу, начинаются остановки работ, угрозы, а то и разрыв отношений, суды и т.д.
А наша цель, напомню – недорогой переезд.
То же касается фиксации стоимости, вопросы взаимосвязаны. Наверное, где-то бывает так, чтобы ТЗ зафиксировали, а стоимость – нет, но достаточно редко 😊. Как только заказчик уломал подрядчика отойти от ТЗ и чего-то доделать (без изменения стоимости), как только лёд тронулся – всё, включился режим «получить как можно больше за уплоченные деньги».
Когда заказчик знает стоимость заранее, он мысленно эти деньги уже отдал, или потерял. И хочет получить за них максимум, а не какое-то компромиссное решение. Это совершенно нормальное поведение, скорее даже бессознательное – и оттого не особо управляемое.
А наша цель, напомню – недорогой переезд.
Всегда ли так происходит? Ну вот срач, разборки, угрозы и т.д.? Нет. Почему? Потому что опытные подрядчики нашли выход – закладывать риски в оценки. Если мы совершенно точно знаем, что заказчик будет требовать больше, чем написано в ТЗ, что он будет настаивать на неизменности фиксированной стоимости, и даже знаем (по статистике), сколько там этих доп. требований и доп. задач будет, то почему бы… Ну, сами знаете. Почему бы не умножить оценку на 2, 4 или 10 в самом начале – и назвать заказчику уже умноженную.
А наша цель, напомню – недорогой переезд.
Вот такая простая математика. Никто не хочет работать в минус, за свой счёт и т.д. Мало кто может в кризисной ситуации долго сраться с заказчиком. Редко помогают «грамотно составленные договоры и ТЗ». Поэтому оптимальный способ – перезаложиться.
А наша цель, напомню – недорогой переезд. Надоела красная нить этой главы? :) Ну а я что сделаю – не хотел, чтобы мысль ускользала, ведь вы точно не согласны минимум с половиной того, что я написал.
Так вот, если мы хотим сэкономить, нам нужно избежать перезакладки. Стоимость не должна быть умножена на 2, 4 или 10. Наиболее разумный способ – не фиксировать ТЗ и стоимость. Увы и ах.
Если стоимость не фиксировать, то у заказчика будет срабатывать естественное ограничение: любое новое требование, любая новая задача – дополнительные деньги. Со стороны подрядчика никаких препятствий не будет – чего ж не поработать за новые деньги.
Понимаю, это дополнительная ответственность и, чего уж там – геморрой для заказчика. Но, как ни парадоксально, при таком подходе заказчик заплатит меньше, а результат получит быстрее и более качественный.
А наша цель, напомню – недорогой переезд.
Помните же, что такое «качество»? Это степень соответствия требованиям потребителя. Если платишь отдельно за каждое своё требование, то невольно будешь этими самыми своими требованиями более качественно управлять. И окажется, что многие хотелки тебе вовсе и не нужны.
Возникает резонный вопрос – а как контролировать баланс выплаченных денег и выполненных работ? А то ведь в голове заказчика, после прочтения этой главы, мысль: платишь-платишь, платишь-платишь, а за что, а когда оно закончится, а сколько ещё платить?
Определение бюджета
Сначала про общий бюджет. В прошлой главе вам, наверное, показалось, что его нет. Но он есть, и известен в самом начале проекта. Только определяется немного не так, как обычно.
В случае переезда объём и сложность работы известны намного точнее, чем при обычном внедрении – 3 тысячи слов выше должны были об этом рассказать. Известны все процессы, которые надо воспроизвести. Понятно, как примерно они должны работать. Есть, с чем сравнить и сверить. Все доработки сведены в реестр, их назначение всем понятно. Короче, известно почти всё и заранее.
В обычном внедрении – очень много неизвестного и непонятного. Выстраиваются новые процессы, которые раньше никто не видел – не известно даже, будут ли они работать. Внедряются новые подсистемы и механизмы, которых в старых системах не было – никто не знает даже того, как они вообще должны работать и выглядеть. А какие цифры должна выдавать новая система – понятно весьма и весьма приблизительно. Да, у этого проекта тоже есть бюджет, известный заранее. Точнее, названный заранее – как ставка в казино. Понятно ведь, что нельзя с какой-то разумной точностью оценить то, чего никто не видел, не понимает, а когда увидит – не будет знать, как проверить.
Теперь, наверное, понятно, в чём разница бюджетов по их качеству. В переезде бюджет – сухой, поджарый, почти без жировых прослоек. Потому что объём и сложность работ – понятны. Во внедрении бюджет – как рюкзак ребёнка, которого родители впервые в жизни отправляют в поход с ночёвкой. Хорошо, если рюкзак всего один 😊.
Итак, бюджет при переезде известен заранее. Но, при этом, оплату я рекомендую делать по факту. Противоречие? Нет.
Бюджет вычисляется по статистике других, похожих проектов. Как у грузчиков – они уже таскали рояль с 8-го этажа старой квартиры на 10-й в новой. Да, им не трудно прикинуть, сколько будет стоить такая же операция с другими номерами этажей. Метод оценки таких проектов мы называем методом отклонений.
Метод отклонений очень прост (но нужен багаж выполненных переездов за плечами – опыт грузчика :)). Смотришь на УПП, которую надо «переехать» - на учёт, процессы, доработки, доп. отчёты и обработки, количество пользователей, наличие среди них лидера, вовлечённость ключевых людей в проект – и считаешь два списка: обычное и отклонения.
Всё, что «как у всех» - это обычное. Всё, что не как у всех – отклонения. Например, справочники номенклатуры и контрагентов – обычное. 500 000 номенклатур – отклонение. Учёт НДС – обычное. Ставка НДС 0% - отклонение. Зарплата без сдельных начислений – обычное. Сдельные начисления, привязанные к документам УПП – отклонения. Закрытие 20 счета ежемесячно в ноль – обычное. Длинное НЗП – отклонения. И т.д.
Список этих отклонений примерно известен – хотя, у каждого подрядчика он свой. Чем больше отклонений, тем дороже проект, потому что с отклонениями возиться дольше и сложнее. Что-то сложно само по себе, что-то – конкретно в ЕРП, с чем-то возникают проблемы при переносе данных.
Собственно, вот так и составляется бюджет. Берём составленные списки – обычное, отклонения, реестр доработок, используемые доп. отчёты и обработки – и ищем в прошлом опыте максимально похожий проект. Какие-то отличия всё равно будут – их оцениваем отдельно. Всё.
Ну и понятно – чем больше проектов за плечами, тем точнее оценка. Могу ошибаться, давно в институте учился – это же регрессионный анализ? Когда есть математическая модель, мы ей скармливаем значения предикторов (отклонения, например), она вычисляет результат, мы её потом корректируем (давая новые примеры, или уточнённые старые).
Или это про ИИ?
Контроль бюджета
Теперь, наверное, понятно, как контролировать бюджет. У вас есть достаточно чёткий список всего, что надо сделать. Есть бюджет – сколько примерно весь этот список будет стоить. Есть прогресс выполнения задач – вы же их можете смотреть, проверять, принимать (в разрезе процессов, документов, отчётов, остатков и т.д.). И главное – вам есть с чем сравнить (старая УПП). Поэтому ваша оценка «да, сойдёт» будет намного точнее, чем при внедрении (когда вы сравниваете с ТЗ).
Ну вот, перед вами будет два прогресс-бара, или burndown chart (если скрамом увлекаетесь): прогресс решения задач и прогресс расхода денег.
На практике, правда, заказчик обычно таким контролем не заморачивается. Не знаю, почему.
Сопровождение до и после
Так, пора бы остановиться… Ладно, последняя короткая глава.
Стоимость проекта может быть ещё ниже, если был опыт совместной работы по сопровождению старой УПП с этим же подрядчиком. Точнее – с этими же людьми. Если программисты сопровождали УПП несколько лет, то они уже знают процессы, людей, узкие и проблемные места, где какой бардак с остатками, какие разделы учёта хромают или не используются.
Раньше, когда до прекращения поддержки УПП оставалось несколько лет, я много говорил и писал про этот фактор, но сейчас от него проку уже мало – остался один год. Если кто-то сейчас кинется искать подрядчика, то уже не на сопровождение, а на проект.
И второй фактор, связанный – будет ли этот же подрядчик вас сопровождать после проекта. Точнее, будут ли сопровождать эти же самые люди (передача клиента после проекта на сопровождение в другой отдел той же компании – всё равно, что смена подрядчика).
Если будут, то проект пройдёт лучше. Кто не собирается с вами работать после проекта, осознанно или неосознанно будет стремиться не к результату, а к подписанию акта. Это нормально, таков проектный бизнес – надо заканчивать одни проекты и быстрее начинать другие. К сожалению, иногда это приводит к снижению качества работ, особенно в финале проекта.
Ну а кто собирается с вами работать и после проекта, будет автоматизировать, как для себя. Ему ж потом всё это сопровождать. И обратную связь ему же слушать («понавнедряли нам тут»).
