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

Текст для меня необычный, потому что – конкретный. Ну, насколько тема управления проектами может быть конкретной. В статье изложен практический подход к выполнению проектов определённого, вполне конкретного типа.

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

Ну всё, переходим к делу. Итак, у нас УПП, и нам надо перейти на ЕРП – побыстрее и подешевле.

Концепт «Переезд»

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

Попробую объяснить на контрасте. Обычный концепт для ЕРП – «внедрение». Применяется в нескольких случаях. Самый вот прям подходящий – когда у заказчика не было никакой автоматизированной системы (такое бывает, кстати, не удивляйтесь). Были эксельки, ка��ая-нибудь Бухгалтерия предприятия для рег.учёта и ЗУП для зарплаты. В этом случае ЕРП внедряется почти с нуля – неоткуда перенести данные, не было автоматизированных процессов, отчётов и т.д. Поэтому надо обследовать все процессы, решать, что автоматизировать, как это сделать, причёсывать-нормализовать (или создавать с нуля) НСИ, разрабатывать всякие способы распределения расходов и т.д. Короче, делать проекцию реальных процессов на учётные с нуля.

Проекты по концепту «внедрение» обычно дорогие, т.к. требуют очень много работы аналитиков и консультантов – тех, кто процессы изучает, на ЕРП перекладывает, функциональные разрывы ищет, документацию пишет и т.д. По разным оценкам, от 50 до 80% стоимости проекта.

А теперь представим – у заказчика давно внедрена и успешно эксплуатируется УПП. Она всех устраивает, и решает все задачи, которые перед ней поставлены. Какие процессы хотели и могли автоматизировать – автоматизировали. Да, у большинства в 1С нет работающего производственного планирования – так его и в ЕРП не будет. Но в остальном УПП давно стала неотъемлемой, привычной частью бизнеса. И никто не собирался её менять, но…

Но поддержка УПП прекращается, и надо переходить в другую программу. Да, есть варианты оставить УПП, поставить рядом БП и ЗУП, сделать обмен и жить дальше. Нормальные варианты, но я их в данной статье не рассматриваю. Большинство выбирают ЕРП или КА2 (в контексте статьи считаем, что это почти одно и то же, и вся информация одинаково годится для обеих конфигураций).

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

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

А уж потом, после переезда, что-то развивать в ЕРП, запускать новые для себя подсистемы, менять подходы к учёту затрат и т.д. Если будет потребность или лишние деньги. Обратите внимание – ровно то же можно было делать и с УПП, останься она на поддержке.

Ещё для ЕРП бывает концепт «перевнедрение», когда кто-то внедрил неправильно, ничего не работает, всё плохо и вообще. Зачастую внедрял сам заказчик, желая сэкономить, что-то пошло не так, а сил и желания довести до ума не хватило. Помучились и пошли к подрядчикам. Концепцию «перевнедрение» я привёл для разнообразия, чтобы рассматриваемый спектр вариантов был пошире 😊

Выбирайте тех, кто знает обе системы

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

Если подрядчик не знает ЕРП, то тут вроде и обсуждать нечего 😊. Понятно, что речь идёт об относительном, а не абсолютном знании – никто не ведает всея ЕРП. Но основную функциональность знать всё-таки неплохо бы. Иначе заказчику придётся оплачивать её изучен��е. Оно не будет звучать, как изучение – есть хорошие слова «анализ» и «моделирование», под которые всё можно завернуть. Ещё раз акцентирую внимание: какие-то вещи – узкие, тонкие, глубокие – любой подрядчик будет изучать за деньги заказчика в ходе выполнения проекта. Но чем обучения меньше, тем проект дешевле.

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

При переезде из УПП в ЕРП такие люди (знающие УПП) сэкономят огромное количество времени и денег, т.к. поймут процессы и доработки заказчика даже без его объяснений. Зачастую даже лучше, чем пользователи заказчика, которые работают с 2-3 документами/отчётами, могут показать что делают, но не понимают, частью какого процесса их действия являются.

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

Дорожная карта

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

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

Обследование процессов

Оно нужно, но в очень небольшом объёме. Обычно достаточно 1-2 дней. Собственно, за него и деньги-то можно не брать с заказчика.

Напомню, мы же переезд делаем. Что именно надо перевезти из УПП в ЕРП – нам известно. Точнее, для составления «списка вещей» достаточно провести 1-2 встречи с тем, кто знает почти всё. Лучшие кандидаты – ИТ-директор, или местный программист 1С, или главный бухгалтер, или финансовый директор бывает хорошо погружён. Короче, тот, кто в курсе большинства процессов.

Чтобы была понятна разница с обычным обследованием, попробую объяснить. В обычном обследовании приходит аналитик от подрядчика, ему дают человека (например, из производства), и человек долго рассказывает аналитику, как у них протекает процесс со всеми составляющими, и как всё это отражается в системе. После чего аналитик ещё отдельно смотрит всё это в УПП (а если никогда не видел УПП – очень долго смотрит 😊). В обычном проекте всё это нужно посмотреть и узнать, т.к. цель – не перетащить учётный процесс из УПП в ЕРП, а автоматизировать живой процесс в ЕРП, не особо оглядываясь на то, как он жил в УПП. За эту работу аналитика надо заплатить – она довольно внушительная по времени.

В случае переезда мы видим, как протекает процесс, в самой УПП. Да, там не все детали видны – но на этап�� обследования они и не нужны. Мы ведь перетаскиваем учётный процесс практически «как есть», т.к. он всех устраивает. С какими-то изменениями, понятно, но их будет не много.

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

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

Ну, вы поняли. У большинства процессов, документов, справочников, отчётов УПП есть аналоги в ЕРП. Список этих аналогов, и вариантов их использования, подрядчику известен. Перечень того, что плохо конвертируется при переходе – тоже (справочник Проекты, номенклатурные группы, счета в документах и т.д.).

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

Не делайте нового

Ну, это понятно из концепта. Если у вас в УПП было только объёмно-календарное планирование продаж – в ЕРП его и запустите, не лезьте в цеховое планирование. Если у вас не было автоматизированного бюджетирования – пока и не будет. Не знали точно своих дефицитов – пока и не узнаете.

Точнее так: не делайте нового именно в рамках проекта. Иначе он перестанет быть переездом, и станет обычным внедрением. А значит – в разы дороже, дольше и нервнее.

Потом сделаете.

Обследование доработок

УПП крайне редко бывает без доработок. Если у заказчика такая – повезло, переезд обойдётся ещё дешевле. Но я буду рассматривать случай, когда доработки всё-таки имеются – в небольшом или среднем количестве. Понимаю, что оценки мои субъективны, но иначе вряд ли получится. Тут дело не только в количестве доработок, в смысле количестве строк кода, доработанных или добавленных объектов, но и в их структуре, сложности, изолированности. Бывает 10 строк кода, которые существенно меняют расчёт себестоимости, а бывает 5000 строк и 50 объектов, которые создают изолированный контур (вроде интеграции с СКУД), уже написаны на управляемых формах и перенести их в ЕРП – дело нескольких дней.

В среднем, по моему опыту, объём доработок всё-таки или небольшой, или средний. Из этого и буду исходить.

Так вот, обследование доработок в случае переезда – процесс несложный. Но, см. выше – нужен программист, который хорошо знает и УПП, и ЕРП. Он сравнит доработанную конфигурацию с типовой, увидит все доработки, по большей части из сам разберётся, зачем они нужны, что делают и есть ли у них аналог в ЕРП. А которые не поймёт – попросит объяснить.

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

По итогу программист составит перечень доработок, кратко изложит назначени�� каждой, есть ли типовой аналог в ЕРП (такое бывает), насколько сложно портировать доработку в ЕРП (бывает – легко, бывает – очень сложно и дорого). Далее все смотрят на этот список и принимают решения – что тащить с собой, что не стоит. Бывает такое – перенести доработку стоит дорого, а в УПП ей почти не пользовались. Чего на неё время и деньги тратить?

Что останется в списке – то попадает в состав работ проекта. Это надо будет доработать.

Отчеты и обработки

С отчётами и обработками какая обычно проблема в УПП: их дофигищща. За годы эксплуатации чего только не понаделали – и внешние печатные формы, и отчёты (непонятно кому нужные), бывает даже отдельный отчёт, который – просто вариант типового, и обработки заполнения.

Главная проблема всего этого – не понятно, что из этого используется, а что – нет. Если перед нами 10 объектов, выяснить можно и пешком – просто спросить. А если их 200 или 500? Можно, конечно, попробовать составить реестр, опросить пользователей, но… При запуске обязательно окажется, что перенесли то, что не нужно, и не перенесли то, что каждый день используется.

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

Потом, ближе к запуску (месяца за 3, например), заглянуть – и реестр будет готов. Чем пользуются, кто, как часто. И всё, можно перетаскивать в ЕРП (искать аналоги, или адаптировать существующие отчёты и обработки).

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

Не используйте ТЗ

Технические задания (ТЗ), частные технические задания (ЧТЗ), листы требований (ЛТ) и прочие подобные бумаги – штука полезная и нужная, но не в нашем случае. У ТЗ есть несколько назначений, но ключевое, именно в проектах – это фиксация договорённостей.

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

И заказчик прав, говоря «ТЗ – это что-то для программистов». Точнее, это не для программистов, а для подрядчика, как юридического лица – это документ, на который потом можно ссылаться. Мы сделали то, что хотел заказчик – вот бумажка, всё написано-нарисовано, подпись стоит.

Второстепенное назначение ТЗ – передача информации от аналитика разработчику. Это мы тоже убираем в нашем случае – читайте ниже.

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

Если переживаете, что без ТЗ кому-то из людей подрядчиков не будет понятно, что и как сделать – не переживайте, всё им понятно. А что будет не понятно – они всё равно спросят, независимо от наличия ТЗ.

Кстати, без ТЗ вопросов будет больше, они будут точнее и глубже – а нам это и нужно. Если есть хорошее ТЗ, понятное разработчику, он вообще вопросов не задаст – просто сделает то, что написано. А если написана была чушь?

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

Собственно, на этом и приёмка строится. Заказчик сравнивает не с ТЗ, которого не понимает, а со старой системой, в которой проработал долго и плодотворно. Предваряя возражения подрядчиков о том, что «заказчик будет бесконечно менять требования» - не будет, см. ниже про отказ от фиксированной стоимости.

Отказ от фиксированной стоимости

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

Итак, наша цель – недорогой переезд.

Любая фиксация создаёт проблемы ближе к концу проекта. Упомянутое выше ТЗ – это фиксация требований. Я постарался достаточно подробно объяснить, к чему приводит фиксация. Неприятность её ещё и в том, что проблемы вылезают не сразу. В начале заказчик подписывает ТЗ, которого не понимает. Потом он даже принимает часть работ по этому ТЗ – всё или почти всё, что будет ему сдано до начала эксплуатации ЕРП. Потому что тоже не понимает – ему сдают работы на копии, на ограниченных тестовых данных. Заказчик говорит «ну, вроде то, что надо». А когда сам, своими руками, на живых данных, в реальных процессах начинает этим пользоваться – вот тут-то и вылезают реальные требования. Которые могут не совпадать с изначальными на 100 %.