“Всё работало и само все сломалось. “
“После обновления ваша 1С перестала работать.”
“Вы там что-то меняли, дак вот теперь оно не работает." (с)
Тадам. Письмо упало в ящик. Смахиваю экран телефона, смотрю заголовок письма, и мысленно чертыхаюсь.
Не люблю я вот такие письма, в них вроде и не претензия, но как бы намек, что ты несешь ответственность за проект, который закончился полгода назад и ты считал, что благополучно передал его на поддержку, отдал инструкции по эксплуатации, бэклог изменений конфига и даже инструкции как не запороть при обновлении. А может это просто просят меня как профессионала помочь)
По большей части, моя деятельность – это участие в проектах внедрения, поэтому срочные и непредсказуемые задачи и проблемы, которые возникают в сданных проектах, негативно сказываются на моем желании реагировать на них.
Что делать с этим? Все как обычно – разбираться, объяснять и делать так, чтобы это не повторялось.
Добро VS Зло
Мы в своей практике автоматизации часто используем учетные системы 1С и респектуем за открытый исходный код и разнообразие конфигураций.
Это круто, потому, что учетную систему бизнес уровня можно адаптировать под нужды клиента, а не изменять процессы в компании под программу.
Зачастую, клиенты сидят уже на готовых конфигурациях поставщиков и им требуется незначительные доработки. Кнопочку тут, автозаполнение здесь, отчет там.
Открытый исходный код – это одновременно и благо и зло.
Благо потому, что можно допилить фичи, базируясь на уже какой-то готовой конфигурации, в качестве примера, недавний проект – автоматизация учета транспортных услуг на базе Бухгалтерии, тыцк.
А зло это то, что конфигурации, нуждающиеся в постоянном обновлении со стороны производителя, например, такие как бухгалтерия или комплексная, и изменять их в части сложных механизмов “не стоит”, потому как стоимость их поддержки может возрасти колоссально, и не с текущим обновлением, а с каким нибудь “мажорным” которое прилетит через год, а потом еще одно и еще.
Почему уходят деньги на сопровождение 1С?
То, что жизнь меняется и бизнес-задачи возникают постоянно – это нормально, и за адаптацию под это системы приходится платить. А вот за что еще можно платить?
"Неграмотные" спецы
Вариантом возрастания стоимости содержания доработанной программы может быть, когда ее модифицировал не очень грамотный спец и “грубо” вся конфигурация снята с поддержки, все изменения прямо вписаны в существующие модули и формы, нет комментов, нарушена методика работы программы (так как закладывал разработчик конфигурации) и подобные вещи.
Сильно переделали
Конфигурация, которая “перепилена” вдоль и поперек под нужды клиента. Такую конфигурацию сложно содержать при обновлениях, потому что необходимо отслеживать, что поменялось в конфигурации поставщика, что у тебя изменено в конфигурации, есть ли фича в обновлении, которая закрывает твои доработки, нужно ли их отключать или модифицировать, а что еще нового в конфигурации поставщика, что ты хотел доделывать и т.п.
Мошенники
Недобросовестные разработчики могут привязывать к себе клиента на так называемую абонентскую плату или на сопровождение только у них потому, что только они знают, как была реализована та или иная фича в конфигурации поставщика, хуже того, они могут намеренно сделать “сложно” поддерживаемый код, скрыть его или обфусцировать его так , чтобы клиент никуда не делся с такой поддержки.
Никто ни за что не отвечает
Я участвовал в проектах, где информационную систему сопровождали сразу несколько подрядчиков и консультантов, причем арбитражем между ними выступал сам Заказчик. Чем заканчиваются разборки после кого сломалось? Ответ очевиден – “это не мы, это они!”. Разборки, доказательства, аналитика, встречи – все это деньги и время.
Что делать?
Я в своей практике проектов автоматизации учета всегда стараюсь сделать так, чтобы решение было максимально легко поддерживаемым разработчиком или консультантом, или IT отделом Заказчика.
В некоторых случаях, лучше даже не реализовывать то, что просит Заказчик потому, что сейчас он, например, горит идеей в маркетинге реализовать в бухгалтерской программе CRM систему, с воронками, чатами, интеграцией с сайтам и каналами лидов, но, из своего опыта, я понимаю, что лучше так не делать, потому что это стратегически невыгодно для него. Невыгодно и для меня потому, что реализованный проект начнет высасывать деньги в долгосрочной перспективе, опять же из-за обновлений, из-за меняющихся задач бизнеса и нужна быстрая адаптация.
На заметку менеджеру
Вот некоторые принципы, которыми мы руководствуемся при внедрении, автоматизации учета и модификации программных решений, и рекомендуем своим Заказчикам придерживаются их же:
- максимально укладывать учет процесса Заказчика в типовую модель программного решения, а тут половина работы на плечах Заказчика, и это тоже сложно – надо изменять процессы в компании, договариваться с персоналом, проявлять свое умение управлять!
- если программу нужно много “доделывать” под задачу, может есть смысл ПОДОБРАТЬ другое соответствующее программное решение, а не “пилить” имеющееся, естественно прикинув совместно с Заказчиком стоимости покупки, доработки, содержания, интеграции с другими системами, и вообще перспективы!
- использовать интеграционные механизмы по максималке, а именно (если говорить в рамках продуктов 1с):
- внешние печатные формы, отчеты, обработки заполнения
- расширения конфигурации
- переопределяемые модули
- обмены данными - просить исполнителя оформить инструкции, планы, описание изменений программы, изменений методики. Много документов это хорошо, но дорого. Документацию также надо актуализировать, поэтому объем должен быть рациональным.
- при одновременной работе нескольких подрядчиков в проекте их нужно согласовывать и, как минимум, закрепить функции интеграции с другими подрядчиками за одним из них
