Доработка за 50 тысяч, которая потом обходится в 500 тысяч Когда компании заказывают доработку 1С, почти всегда обсуждают только один вопрос: «Сколько стоит сделать?» Но гораздо важнее другой вопрос: «Во сколько обойдётся владение этой доработкой через несколько лет?» Любая нестандартная разработка становится частью вашей системы. И если она выполнена без архитектуры, документации и учёта будущих обновлений, со временем начинает создавать проблемы. Что происходит дальше? — обновления 1С становятся сложнее и дороже; — каждое новое изменение требует всё больше времени; — появляются конфликты с типовым функционалом; — растёт риск ошибок после обновлений; — разобраться в доработках может только тот, кто их писал. В итоге небольшая задача, которая стоила 50 тысяч рублей, через несколько лет может потребовать сотни тысяч на сопровождение, исправление и адаптацию. Это и есть технический долг. Он не появляется за один день. Он накапливается постепенно — после каждой доработки, выполненной «быстро», «временно» или «и так сойдёт». Поэтому перед разработкой важно оценивать не только стоимость внедрения, но и стоимость дальнейшего сопровождения. Хорошая доработка — это та, которая: ✔️ не мешает обновлять 1С; ✔️ документирована; ✔️ понятна другим специалистам; ✔️ легко поддерживается через несколько лет; ✔️ не создаёт новых проблем при развитии системы. Если ваша база развивается уже несколько лет, есть высокая вероятность, что технический долг уже накопился. И чем раньше его обнаружить, тем дешевле будет его устранить. 📄 Закажите аудит накопленного технического долга. Мы оценим состояние вашей системы, покажем потенциальные риски и подскажем, какие доработки уже начинают обходиться бизнесу слишком дорого.
АС ИТ | Партнер Битрикс24 | Партнер 1С
🫢Почему опасно, когда всю вашу 1С знает только один человек «По 1С лучше спросить у Сергея. Только он знает, как там всё настроено». Знакомая ситуация? На первый взгляд, ничего страшного. Есть опытный специалист, который годами работает с системой, знает все доработки и быстро решает проблемы. Но для бизнеса это серьёзный риск. Что произойдёт, если завтра этот специалист: — заболеет; — уйдёт в отпуск; — уволится; — будет занят другим проектом; — просто не сможет оперативно подключиться? В этот момент может выясниться, что никто больше не знает, как работает ваша 1С. Почему был изменён этот документ? Как настроен обмен? Какие доработки внесены в базу? Что нельзя обновлять без дополнительной проверки? Ответ один: «Это знает только Сергей». И пока Сергей недоступен, работа останавливается. Проблема здесь не в специалисте. Проблема в том, что знания о критически важной системе хранятся в голове одного человека. Надёжная поддержка 1С строится иначе. ✔️ Доработки документируются. ✔️ Решения по задачам сохраняются в базе знаний. ✔️ История изменений доступна команде. ✔️ Критичные процессы описаны. ✔️ Есть специалист, который может подхватить задачу. Тогда болезнь, отпуск или увольнение одного человека не превращаются в аварию для всей компании. Проверьте свою систему прямо сейчас. Если ваш специалист завтра станет недоступен, другой человек сможет разобраться в вашей 1С без нескольких недель изучения базы? Если ответ «нет» — ваша система уже зависит от одного человека. И лучше обнаружить этот риск до того, как он превратится в реальную проблему.
✅«Как объяснить задачу программисту, если вы не программист?» Многие руководители и бухгалтеры считают, что перед обращением к специалисту нужно самостоятельно составить техническое задание. Из-за этого они пытаются описывать таблицы, справочники, документы, регистры и даже предлагать способы реализации. На самом деле это не их задача. Ваша задача — объяснить, какой бизнес-процесс работает неправильно и какого результата вы ожидаете. Разобраться в причинах, изучить процесс, задать правильные вопросы и перевести бизнес-потребность на язык разработки — обязанность аналитика. Именно поэтому хороший специалист никогда не начинает работу с вопроса: «Как это запрограммировать?» Он сначала выясняет: ✔️ что происходит сейчас; ✔️ что должно происходить; ✔️ кто сталкивается с проблемой; ✔️ как это влияет на работу компании; ✔️ какой результат необходимо получить. Только после этого формируется техническое задание для программиста. Такой подход позволяет избежать недопонимания, лишних доработок, потери времени и дополнительных расходов. Если от вас требуют самостоятельно написать техническое задание, стоит задуматься, действительно ли специалист понимает вашу задачу. Хороший аналитик берёт эту работу на себя. 📄 Мы подготовили шаблон постановки бизнес-задачи, который поможет правильно описать проблему и значительно ускорит работу специалистов. 💬 Напишите в комментариях «Шаблон», и мы отправим его бесплатно
Что должно происходить в первые 30 минут после сбоя 1С Когда в 1С возникает критическая ошибка, время начинает работать против бизнеса. Первые 5 минут. Регистрация аварии Любое обращение должно быть зафиксировано. Специалист уточняет: * что именно произошло; * когда возникла проблема; * сколько сотрудников не могут работать; * какие операции сейчас заблокированы; * появились ли сообщения об ошибках; * были ли перед этим обновления, изменения настроек или перебои с оборудованием. На этом этапе важно собрать максимум информации, чтобы не терять время на повторные уточнения. 5–10 минут. Определение приоритета Не каждая ошибка требует одинаковой скорости реакции. Одно дело — если один пользователь не может распечатать документ. Совсем другое — если остановилась работа всей компании, не проходит обмен с банком или невозможно провести реализацию. От правильной оценки приоритета зависит скорость восстановления работы бизнеса. 10–20 минут. Диагностика причины Хороший специалист не начинает сразу менять настройки или переустанавливать программу. Сначала проводится диагностика. Проверяются: * состояние сервера; * доступность базы данных; * последние изменения в системе; * журналы регистрации; * наличие блокировок; * работа лицензий; * сетевое подключение; * результаты последних обновлений. Главная задача — определить первопричину, а не бороться с её последствиями. 20–25 минут. Информирование клиента Одна из самых распространённых ошибок технической поддержки — молчание. Клиент не понимает: * что происходит; * занимается ли вообще кто-то его проблемой; * сколько ещё ждать; * сможет ли компания сегодня работать. Даже если проблема ещё не устранена, специалист обязан сообщить: * что уже проверено; * какая предварительная причина обнаружена; * какие действия выполняются сейчас; * когда ожидать следующее обновление информации. Это снижает уровень стресса и помогает руководству принимать решения. 25–30 минут. Восстановление работы и проверка После устранения причины работа не заканчивается. Необходимо убедиться, что система действительно функционирует корректно. Проверяются: * вход пользователей; * проведение документов; * обмены с другими системами; * печатные формы; * работа интеграций; * основные бизнес-процессы компании. Только после успешного тестирования можно считать, что авария устранена. Важно быстро разобраться в причине, восстановить работу системы и убедиться, что проблема не повторится через несколько часов или дней. Именно поэтому профессиональная поддержка 1С строится на чётком алгоритме действий, а не на импровизации. ⸻ 💬 А теперь сравните этот алгоритм с работой вашей текущей поддержки. Когда у вас происходит сбой в 1С: * быстро ли реагируют специалисты; * держат ли вас в курсе происходящего; * ищут ли первопричину или просто временно устраняют последствия? Если хотя бы на один из этих вопросов вы ответили «нет», возможно, проблема не в 1С, а в организации технической поддержки.
⏰«Ошибка исправлена». Почему через неделю она появилась снова? Клиент получает сообщение: «Исправлено». Всё работает, проблема исчезла. Но проходит несколько дней или недель — и ошибка возвращается. Почему так происходит? Чаще всего причина в том, что устранили не источник проблемы, а только её проявление. История клиента : Обращение бухгалтера с жалобой: после обновления 1С периодически переставал работать обмен с банком. Специалист, который обслуживал базу раньше, каждый раз подключался удалённо, заново настраивал обмен, и всё снова работало. Но через несколько дней проблема повторялась. Руководство уже смирилось с мыслью, что «1С просто иногда ломается». Когда мы начали разбираться, выяснилось, что дело было вовсе не в настройках обмена. После обновления программы изменились требования к криптопровайдеру и сертификату электронной подписи. Сертификат использовался старый, а на одном из рабочих мест были установлены несовместимые версии компонентов. Каждый раз предыдущий специалист вручную восстанавливал обмен, но не устранял настоящую причину. Мы проверили все рабочие места, обновили необходимые компоненты, перенастроили криптографическое ПО, протестировали отправку и получение выписок в разных сценариях и убедились, что обмен стабильно работает. После этого проблема больше не возвращалась. 🔦Что должно входить в качественное исправление 🔰Поиск первопричины. Необходимо понять, почему возникла ошибка, а не только где она проявилась. 🔰Тестирование реальных сценариев. Проверяются все ситуации, в которых проблема может повториться: разные устройства, версии программ, действия пользователей и нестандартные условия работы. 🔰Проверка связанных компонентов. Любое изменение может повлиять на другие части системы. Поэтому важно убедиться, что исправление не вызвало новых ошибок. 🔰Гарантийный период. После внедрения решения специалисты продолжают наблюдать за системой. Если проблема проявится повторно из-за той же причины, она устраняется без повторной оплаты. А какая ошибка возвращается у вас снова и снова? Расскажите в комментариях — разберёмся, почему это происходит и как решить проблему окончательно.
