Санто Групп 
Тендеры и лиды
Информация
На предприятии уже есть бухгалтерская программа, система расчётов, диспетчеризация, иногда личный кабинет. Но перед закрытием месяца сотрудники всё равно выгружают данные, пересчитывают часть начислений в Excel и выясняют, какая сумма правильная. Такие ситуации мы разбираем на встречах с ресурсоснабжающими компаниями.
У каждой программы своя задача, и отдельно она может работать вполне нормально. Ручная работа обычно возникает между ними. Показания получены, но ещё не проверены. Расчёт выполнен, но его результат приходится исправлять при подготовке документов. Оплата отражена в бухгалтерии, а в отчёте сбыта потребитель всё ещё числится должником.
Мы в «Санто Групп» занимаемся внедрением и разработкой на 1С. На примере двух проектов разберём, какие решения помогают связать эти операции. Здесь будет отраслевая специфика теплоснабжения, но сама задача знакома и другим предприятиям: как передавать данные между системами, чтобы сотрудникам не приходилось заново собирать и проверять их на каждом этапе.
Заказчик редко начинает разговор с описания архитектуры. Он объясняет, что приходится делать сотрудникам.
На одной разбираем процесс: данные от расчётного центра загружаются в отраслевую программу, часть распределений и годовая корректировка выполняются в Excel, документы готовятся в другой системе. При передаче данных между ними приходится вмешиваться вручную. В другом разговоре основная тревога связана с платежами: если они изначально распределены неверно, обмен перенесёт ошибку и в отчёт по задолженности.
Отдельная тема таких бесед - изменения прошлых периодов. Документ исправили в бухгалтерии, но в расчётной программе осталось прежнее состояние. Через некоторое время две базы показывают разные суммы по одному контрагенту. Формально интеграция есть, но сотрудники всё равно вынуждены сверять данные.
При обследовании особенно важны места, в которых человек проверяет, исправляет или заново вводит уже существующую информацию. Здесь можно увидеть, каких правил или инструментов не хватает предприятию.
Например, просьба «нам нужен отчёт по дебиторке» может привести к разработке новой таблицы. Только таблица не исправит распределение оплат, из-за которого долг отображается неверно. Сначала нужно понять, где возникает расхождение и кто вправе его исправлять. Иначе получится ещё один красивый отчёт, которому сотрудники не доверяют.
В обоих проектах основой стала «1С:Управление теплосетью 2», связанная с бухгалтерской системой. При этом состав данных и повседневная работа пользователей различались.
Количество лицевых счетов само по себе плохо описывает сложность. Важно, какие услуги получает потребитель, как определяется объём, кто передаёт показания, что происходит при неисправности прибора и как учитываются перерасчёты. Именно эти варианты нужно разобрать до массового запуска.
В «Мытищинской теплосети» мы настроили получение показаний из внешней базы MySQL и их дальнейшее использование в УТС 2. Так данные из системы сбора попадали в расчётную программу без повторного набора сотрудником.
Однако успешная загрузка говорит только о том, что система получила данные. Она ещё ничего не говорит об их пригодности для начисления.
Прибор может передавать подозрительные значения. За частью периода показаний может не быть. Прибор могли снять или заменить. Если в таком случае просто подставить всё полученное в формулу, расчёт отработает технически успешно, а его результат придётся разбирать с потребителем.
Поэтому при разработке рабочих мест для теплосетей мы связали загрузку с контролем показаний. Проверки помогают находить отсутствие регистрации, нулевые температуры, выход расхода за заданные границы, резкие изменения показателей. Это признаки для проверки специалистом: сам по себе скачок ещё не объясняет, что произошло на объекте.
Здесь важно сохранить ответственность технической службы. Программа собирает отклонения и показывает проблемные приборы. Специалист выясняет причину, фиксирует состояние оборудования и необходимые изменения. Расчётная служба получает сведения, на основании которых можно выбрать предусмотренный методикой способ расчёта.
Для приборов без автоматического сбора мы разработали отдельное рабочее место ручного ввода. Ручной ввод в таком случае остаётся частью процесса. Задача интерфейса - учитывать периоды эксплуатации и помогать сотруднику не ошибиться, в том числе при снятии и повторном допуске прибора.
Для других отраслей здесь полезен сам принцип. Получить вес со склада, выработку с оборудования или показания счётчика недостаточно. Нужно определить, какие данные допустимо использовать в следующей операции и что делать с сомнительными значениями.
В Мытищах мы создали аналитические рабочие места, которые помогают выявлять ошибки до расчёта тепловой энергии. Такие же задачи контроля решали в «Сибирьгазсервисе».
В разработках для теплосетей мы разделяем проверки по этапам. До расчёта проверяем исходные данные и настройки. После определения объёмов ищем объекты, которые должны были рассчитаться, но не попали в результат. Перед подготовкой документов проверяем то, что может дать расхождения при предъявлении начислений.
Второй этап особенно легко недооценить. Если система не посчитала объект из-за незаполненного условия, в итоговой таблице может вообще не оказаться строки с ошибкой. Отсутствие строки выглядит спокойно. Но предприятие могло не предъявить объём, который должно было предъявить.
Поэтому для проверки нужен и ожидаемый состав расчёта: какие объекты и услуги должны участвовать в данном периоде. С ним можно сопоставить фактический результат и показать сотруднику пропуски.
Есть и менее заметные ситуации. В подробном расчёте - много помещений и строк, а во внешнем документе или на портале требуется свёрнутый итог по услугам. При таком объединении могут возникать расхождения из-за округлений. Мы предусмотрели отображение подобных отклонений, чтобы сотрудник видел, какие документы требуют проверки.
Полезный интерфейс в этих случаях показывает конкретный объект и причину, по которой он требует внимания. Общее сообщение «расчёт выполнен с ошибками» оставляет человеку почти всю работу по поиску.
Подробности проекта и состав выполненных работ - в кейсе «Мытищинской теплосети».
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13806 тендеров
проведено за восемь лет работы нашего сайта.
Вопрос «сможете связать с бухгалтерией?» обычно звучит как проверка технической возможности. На практике за ним стоят несколько решений, от которых зависит дальнейшая работа.
Где создаётся исходный документ? Какая система отвечает за распределение оплаты? Что произойдёт после исправления прошлого периода? Как сотрудник узнает, что изменения не дошли? Какие суммы и разрезы нужно сопоставлять при сверке?
На встречах с ресурсоснабжающими компаниями именно корректировки и взаиморасчёты вызывают подробные обсуждения. И понятно почему: неверно распределённая оплата влияет на задолженность и дальнейшую работу с потребителем. Передать её быстрее технически возможно, но сначала нужно разобраться с правилами распределения.
В «Мытищинской теплосети» мы настроили обмен между УТС 2 и бухгалтерией. Документы, сформированные по результатам отраслевого расчёта, передаются в бухгалтерскую систему; далее используется в том числе ЭДО.
В «Сибирьгазсервисе» к связке УТС 2 и «1С:Бухгалтерии 3.0» добавились федеральная система «Город» и обмены с платёжными агентами. Здесь необходимо согласовать уже несколько потоков: начисления, показания индивидуальных приборов и оплаты физических лиц. В проекте настроили равномерную плату за отопление в течение года и годовую корректировку по фактическому потреблению. Нужно было учесть особенности отопительного и неотопительного периодов, расчёты тепла и горячей воды по прямым договорам с населением.
Для такого процесса недостаточно проверить начисление за один обычный месяц. В набор сценариев проверки стоит включать годовую корректировку и изменения исходных данных: результат должен оставаться понятным и расчётной службе, и бухгалтерии, и потребителю.
При проектировании такого обмена стоит проверять его на изменениях, а не ограничиваться первой успешной передачей. Например, повторно отправить документ, исправить исходные данные, проверить обработку корректировки. Это сценарии для приёмки: они позволяют заранее выяснить, где появятся дубли или расхождения.
При этом бухгалтерия и отраслевое решение могут оставаться отдельными программами. Их согласованная работа зависит от понятных правил ведения данных и контроля обмена. Объединить всё в одну базу - отдельное архитектурное решение, которое тоже требует оценки, а не универсальный ответ на любую проблему синхронизации.
Есть техническая деталь, которая хорошо показывает специфику таких проектов: рассчитанный показатель не всегда нужно предъявлять потребителю к оплате.
Например, объём воды может использоваться как исходная величина для расчёта тепла на её подогрев. В конкретной схеме предприятие предъявляет тепловую энергию, а промежуточный показатель нужен для вычисления. В настройках необходимо различать участие услуги в расчёте и её включение в реализацию.
Дальше результат нужно оформить. В Мытищах мы автоматизировали заполнение комплектов печатных форм по 14 видам договоров с приложениями объёмом более 20 листов. При таком количестве вариантов подготовка документов становится самостоятельным участком автоматизации.
В наших разработках состав пакета можно связать с условиями договора. Одному потребителю достаточно основных документов, другому нужна подробная ведомость по объектам. Массовая подготовка должна учитывать эти различия, иначе после неё сотрудники снова будут вручную собирать индивидуальные комплекты.
В «Сибирьгазсервисе» другой важной точкой взаимодействия стал личный кабинет. Абоненты получили возможность передавать показания, просматривать начисления и оплачивать счета онлайн. Если начисления и оплаты рассогласованы, личный кабинет покажет это потребителю. Поэтому его нужно проектировать вместе с процессами приёма показаний, расчёта и отражения платежей.
По данным проекта «Сибирьгазсервиса», трудозатраты подразделений после внедрения снизились примерно на треть.
Ещё одна ситуация из встреч: абонентский отдел понимает, зачем нужна новая система, но не может самостоятельно собрать данные о структуре сетей и состоянии приборов. Эти сведения находятся у технических подразделений, которыми он не руководит.
Разработчик может добавить обязательное поле. Но это не определит, кто должен его заполнять и к какому сроку. Без договорённостей между службами поле останется пустым, либо его заполнят формально, лишь бы программа пропустила дальше.
Поэтому у каждого критичного набора данных должен быть ответственный со стороны предприятия. Для показаний, состояния прибора, договора, расчётной схемы и оплаты это могут быть разные сотрудники. Важно, чтобы участники понимали, какие следующие операции зависят от их действий.
Рабочее место расчётной службы помогает сделать эту зависимость видимой. Сотрудник видит необработанные отклонения по приборам и понимает, что до расчёта нужен ответ технической службы. После проверки обновляет данные и продолжает работу. Это позволяет обсуждать конкретный объект и конкретную задачу, а не искать причину расхождения в конце месяца.
В филиальной компании обследование усложняется: у подразделений могут различаться программы, услуги и порядок работы. Поэтому состав автоматизации нужно фиксировать по филиалам. Часть подразделений может входить в проект сейчас, другая - оставаться за его рамками. Если это не выяснить заранее, даже число договоров и объектов в оценке окажется неоднозначным.
Планируете автоматизацию? Начните с того, что отнимает время у сотрудников
В проектах «Мытищинской теплосети» и «Сибирьгазсервиса» нам пришлось связать работу нескольких подразделений и систем: от получения показаний до расчётов, документов и оплат. Именно на переходах между этими операциями часто остаются ручные сверки, повторный ввод и поиск расхождений.
Если вы готовитесь к автоматизации, выберите один такой участок и разберите его вместе с сотрудниками. Где они берут данные, что перепроверяют, какие таблицы ведут отдельно? Покажите этот процесс на конкретном примере - с исходными данными, исправлениями и документом, который должен получиться в конце. Это поможет определить требования к будущей системе и понять, какой результат вы хотите получить.
А если программы уже внедрены, но данные по-прежнему приходится сводить вручную, стоит разобраться, почему это происходит. Причина может быть в настройках, обменах или порядке работы подразделений.
Ручные сверки остаются там, где системе не хватает проверок, правил обработки изменений или согласованных действий сотрудников. Поэтому после внедрения полезно посмотреть, какую работу люди продолжают выполнять между программами. Именно эти действия показывают, какие задачи автоматизации ещё предстоит решить.
Надеемся, примеры двух проектов помогут вам увидеть такие участки у себя. Успехов в проектах - и пусть после запуска у команды действительно становится меньше ручной работы.
