Внутреннее облако для аудиторской компании: контрагенты, отчётность и документооборот

К этому моменту мы уже автоматизировали для компании внешние запросы контрагентам и развернули почтовый сервер. Задача вскрыла проблему уровнем выше: автоматизированный кусок работал, но всё остальное вокруг него оставалось разнесённым по не связанным друг с другом местам.

Данные контрагентов жили в файлах и головах сотрудников. Отчётность, которую нужно перепроверять, лежала в выгрузках и таблицах. Документы по проверке в папках на дисках. Учёт в 1С, отдельно от всего. Один и тот же контрагент существовал в четырёх местах в четырёх немного разных видах, и какой из них верный, выяснялось по ходу дела.

Из этого росла вторая проблема: доступ. Пока данные лежат в файлах, вопрос «кто из сотрудников что видит» не имеет технического ответа: у папки либо есть доступ, либо нет. Для компании, которая работает с финансовыми данными чужого бизнеса, это не бытовое неудобство, а прямой риск.

И третья: любая попытка навести порядок упиралась в требование, которое обсуждению не подлежало. Никакие внешние сервисы. Данные клиентов аудитора не выкладываются в чужое облако, этого требует и характер данных, и отраслевое регулирование, под которым компания работает.

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

Систему, которую в компании называют внутренним облаком, и название точное: по возможностям это облачный сервис: веб-приложение, доступное сотрудникам с рабочих мест, с общей базой, файловым хранилищем и правами доступа. По расположению полная противоположность: всё развёрнуто в кластере на серверах заказчика.

Ядро системы это единая база контрагентов. Тот самый контрагент, что раньше существовал в четырёх видах, стал одной записью, к которой привязано остальное: история работы, документы, отправленные запросы и полученные ответы, проверяемая отчётность.

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

Рядом документооборот: документы по проверке хранятся не в папке на диске, а в системе, с привязкой к контрагенту и проверке, в файловом хранилище на серверах компании. Плюс набор вспомогательных модулей, выросших из практики: то, что сотрудники до этого делали руками и одинаково каждый раз.

По возможностям это облачный сервис. По расположению серверы в помещении заказчика. Ровно это сочетание и было задачей.

Разграничение доступа проектировалось не как настройка, а как часть модели системы. В аудите сотрудник не должен видеть всё: у проверки есть состав участников, у данных клиента есть круг допущенных, и этот круг уже, чем список работников компании.

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

Для компании, которую саму проверяют, это не про удобство. Это про способность показать, как устроен доступ к доверенным ей данным, и показать устройством системы, а не обещанием.

Система не заменила учётную систему и не пыталась: 1С остаётся там, где считаются деньги компании. Вместо этого налажен обмен: данные, которые нужны обеим сторонам, ходят между системами, а не переносятся сотрудником руками.

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

Два проекта таким образом сложились в один: первый закрыл канал общения с внешним миром, второй закрыл то, ради чего это общение затевалось.

Автоматизация запросов из прошлого проекта перестала быть отдельным инструментом и стала функцией общей системы.

Локальное развёртывание было не пожеланием, а рамкой, внутри которой принимались все остальные решения. Аудиторская компания работает с финансовыми данными чужого бизнеса; выносить их в стороннее облако нельзя ни по характеру данных, ни по требованиям к их хранению.

Поэтому облачными остались только свойства системы, но не её расположение. Приложение, база, файловое хранилище, кеш и обмен с 1С работают в кластере на серверах заказчика. Файлы лежат в хранилище с S3-совместимым интерфейсом, развёрнутом там же. Это удобство привычного протокола без выноса документов наружу.

Кластер выбран не ради моды на технологию: система стала для компании основным рабочим инструментом, и её недоступность останавливает работу целиком. Кластерное развёртывание это ответ на вопрос, что происходит, когда один сервер выходит из строя.

Сторона эксплуатации важна не меньше кода. Система стоит у заказчика и обслуживается там же, и это часть требования, а не следствие.

Полгода разработки дали компании не набор улучшений, а другой способ работать. Данные перестали быть разрозненными файлами и стали системой, в которой контрагент, его отчётность, документы и переписка стали одним связанным целым.

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

И отдельно: система осталась внутри периметра. Всё, что даёт облачный сервис, компания получила, ничего не отдав наружу.