Доработки в 1С:ERP: покупаете один раз, а платите 5 лет?
Доработка конфигурации - самая крупная строка в счёте подрядчика, и единственная, которая продолжает генерить затраты после сдачи проекта. Разбираю, где проходит граница между доработкой, которая живёт годами, и той, что превращается в техдолг.
Разговор почти всегда начинается одинаково. Заказчик говорит: давайте запустимся без доработок, на типовом. Я отвечаю: но у вас же специфика. И дальше всё зависит от того, где мы проведём черту.
Черта эта дороже, чем кажется. Доработка конфигурации бывает самой крупной строкой в счёте подрядчика: в реальном коммерческом предложении, которое я разбирал в статье про стоимость внедрения, на неё пришлось около 40 процентов. И она же единственная строка, которая продолжает генерить затраты после того, как проект закрыт. Минимум, раз в год-полтора выходят новые существенные релизы платформы и конфигурации, на которые обязательно обновляться, и каждый релиз спрашивает с вас за всё, что вы когда-то доработали в программе.
Отсюда и пугалка, которую вы наверняка слышали: не дорабатывайте, иначе получите чемодан без ручки. Пугалка правдива наполовину. В моей практике неподъёмная система - следствие плохо проведённой границы, а не расплата за доработки как таковые. Даже сильно доработанную «1С:ERP» мы обновляем максимум за неделю. Это нормальный объём работ. Держится он на одном: на том, где проходит граница и как пишется код.
Ядро, к которому мы близко не подходим
Есть механизмы, которые я трогать не даю. Первый в списке - расчёт себестоимости. Причин три, и они разные.
Риск. Себестоимость в «1С:ERP» связана со всем: с производством, складом, закупками, финансовым результатом. Влезая туда со своей логикой, вы рискуете повредить согласованную работу десятка функций. И вылезет это не там, где правили, а через два перехода, в отчёте, который никто не сверял.
Проверяемость. Типовой механизм проверен тысячами внедрений и самой фирмой «1С». Ваш - только вами, в сжатые сроки, на ваших же данных. Как убедиться, что он считает верно во всех сценариях, а не только в контрольном примере? Толком никак.
Деньги, и не разовые. Как только вы переписали расчёт себестоимости под себя, конфигурация перестала быть типовой. Каждый релиз теперь пересобирается руками. Вот здесь и рождается тот самый чемодан без ручки.
Производственные механизмы - из той же породы. Доработки в производстве нужны почти на каждом проекте, но сами механизмы там не проще себестоимости, и в них мы тоже не лезем.
Слой, где дорабатывать нужно
А теперь про место, где мы дорабатываем спокойно и много. Это рабочие места.
Если человеку неудобно работать в системе, мы не переделываем документ и не трогаем механику. Мы делаем ему удобное рабочее место: снаружи интерфейс выглядит так, как ему привычно, а под капотом формирует движения всё тех же типовых объектов. Обновляемость сохраняется - типовые объекты никто не тронул.
Возьмите производство. У мастера в цеху не должно быть перед глазами всей сложности типового документа. Мы это делаем без споров: сложность остаётся в системе, просто человек её не видит. Вот это и есть правильная доработка - добавляет удобство, не ломая механику.
Разница между двумя подходами примерно как между новой приборной панелью и переборкой двигателя. Панель можно перерисовать под водителя как угодно. В двигатель на ходу лучше не лезть.
«У нас уникальный учёт»
Обратная ситуация: заказчик просит уникальности. И чаще всего так называемый уникальный учёт прекрасно ложится в типовой функционал - надо только добавить удобства через те же рабочие места. Люди принимают привычку за уникальность. Особый порядок ввода, особая форма, особый отчёт - за годы это приросло к рукам и стало казаться сутью бизнеса, хотя это оболочка.
Есть одна ситуация, где уникальность настоящая: переход с исторического, сильно допиленного под предприятие решения. Тут на входе понятно - доработок будет очень много. За годы старую систему могли сделать действительно уникальной и очень удобной, и повторить это на типовом решении, которое изначально создаётся универсальным, дорого и сложно.
Здесь выбор не мой, а ваш. Понимаете, зачем вам такое решение, и готовы вложиться сначала в создание, потом в поддержание - идите этим путём. Только потом не спрашивайте лишний раз, почему так дорого: вы заплатили за это сознательно. Если бюджет ограничен, придётся пойти на уступки и смириться, что типовое не повторит какие-то привычки старой системы. И объясняться с пользователями в этом случае будет вся проектная команда сразу - ваша и наша.
Во что этот выбор обойдётся именно вам - в цифрах, а не в ощущениях, - считается на обследовании: старую систему раскладывают на список привычек и функциональных особенностей и оценивают, что из них правда уникальность. Дешевле узнать это до контракта, чем после.
«Маленькая доработка» не бывает маленькой
Ещё одно заблуждение, которое дорого обходится: представление, что доработка равна написанию кода. По нашей практике сама разработка - примерно 60 процентов работы. Остальное: техническое задание около 20 процентов и сдача с приёмкой ещё 20. К любой строчке кода прилипает ТЗ и приёмка, поэтому «да там на полчаса» не стоит полчаса никогда.
Отсюда несколько правил, которые экономят нервы потом.
Оценку программиста закладывайте с запасом. В нашем внутреннем регламенте к оценке программиста добавляется 50 процентов, к оценке консультанта - 30. Это не перестраховка, это статистика по своим же проектам.
Принимать доработку должны те, кто ею будет пользоваться, а не IT-отдел. Если приняло IT, велик шанс, что на опытной эксплуатации значительная часть уйдёт в корзину: сделали не то, что нужно в работе. Я не хочу обидеть айтишников, тут смысловое искажение - то, что для IT главное, для пользователя «да ладно». У меня было три проекта, где принятую IT-подразделением работу бизнес потом разнёс до атомов. IT-служба отряхнулась и продолжила работать, а убытки компенсировал я.
В моей книге это обсуждается подробнее. Один из таких случаев: клиент пытался силами своей IT-службы повторить то, что было сделано в исторической системе. Когда до работы с системой дошли реальные пользователи, нас прогнали с проекта.
И ТЗ должно описывать не только счастливый путь. Хорошее задание описывает отклонения: возвраты, корректировки, ошибки ввода. Иначе программист упрётся в первую же нестандартную ситуацию и пойдёт задавать вопросы - а это сорванный срок.
Документ, по которому видно, чем всё кончится
У западных коллег есть полезная привычка: вести учёт каждого отступления от стандарта и делить отступления по риску. Одно дело - расширение через открытый механизм, совсем другое - прямая правка типового или запись напрямую в таблицы базы. Второе помечается как тяжёлый риск, с которым надо что-то делать, а не жить вечно.
Смысл простой. Отступления накапливаются незаметно. Каждое по отдельности выглядит безобидно, никто их не считает, и к концу проекта у вас на руках уникальный софт под одного заказчика, который уже не обновить.
У нас этот счётчик не наблюдение, а практика: на каждое отступление от типовой заводится своё ТЗ, и реестр отступлений живёт до конца проекта. Когда меня зовут посмотреть чужой буксующий проект, этот реестр я спрашиваю первым. Если его нет, картина «чем всё кончится» складывается не в пользу успеха проекта.
Вам этот документ доступен так же, как мне. Спросите его у своего подрядчика сегодня: есть ли он, сколько в нём строк и на каждую ли есть ТЗ. Ответ «мы ведём это в задачах» означает, что не ведёт никто.
Как решать по каждой доработке
Меня часто спрашивают, считаю ли я окупаемость доработки. Не считаю - и не видел, чтобы такой расчёт кому-то помог. В рублёвой арифметике доработка почти всегда выглядит выгодной: вот стоимость, вот сэкономленные человекочасы, всё сходится. Проигрывает она на другом вопросе: а что с этим будет через три года.
Свежий пример. Заказчик просил сделать сложный механизм формирования расчётно-калькуляционных материалов на «1С:УПП». Я отказался наотрез: делать дорогую доработку на продукте, который снимают с поддержки, - сизифов труд. Вложите деньги в то, что через пару лет придётся выбросить вместе с платформой. Вместо доработки я предложил переход на «1С:ERP», где нужные механизмы уже были. Заказчик согласился и теперь много лет будет получать пользу от этой работы, а не латать умирающую систему.
Я не считал ему таблиц окупаемости. Я объяснил вопросы риска и здравого смысла.
Так что тест для директора короткий, и он не про деньги:
- Что произойдёт, если этого НЕ делать? Если ответ «людям будет непривычно» - это привычка, а не требование.
- Где эта доработка живёт - в интерфейсе или в механике? Панель автомобиля или двигатель.
- Кто её примет? Если в ответе звучит «IT посмотрит» - остановитесь.
- Что с ней будет на следующем релизе и через три года?
Четвёртый вопрос отсекает больше всего.
Как проверить этим подрядчика
Правила выше - не моё изобретение. Рынок внедрения «1С:ERP» зрелый, опытные интеграторы пришли примерно к одному и тому же, каждый однажды обжёгся на доработанном ядре и посчитал, во что обходится потом каждый релиз. Разница между подрядчиками не в знании правил, а в том, соблюдаются ли они на живом проекте.
Проверяется это тремя вопросами, и задать их можно на пресейле, до всяких договоров. Включая нас - спрашивайте и с нас тоже.
- Где у вас проходит граница ядра? Что вы не дорабатываете никогда?
- Как делаются доработки?
- Сколько у вас занимает обновление сильно доработанной Вашей базы?
На третий вопрос вы услышите либо срок в днях, либо рассуждение о том, что всё зависит от многих факторов. Второй ответ тоже информативен.
Система, которую можно обновить за неделю, - это система, которой предприятие пользуется годами. Доработанная до состояния уникального артефакта, которую страшно тронуть, тихо устаревает и в итоге выбрасывается вместе с деньгами, которые в неё вложили. Хорошая доработка добавляет удобство и не мешает системе жить дальше. Плохая покупается один раз, а платится за неё каждое обновление.