Учет, как особый, достаточно сложный и уважаемый вид человеческой деятельности действительно умер. Навсегда ушли те времена, когда человек, нашедший в себе силы освоить премудрости дебета и кредита, сразу становился обладателем магических перков. Он мог разговаривать с налоговой и следить за тем, чтобы не разворовали склад. При том, что не стоял день и ночь рядом со складом с ружьем, а использовал магию цифр, сидя в комфортном кабинете. Теперь с налоговой разговаривает программа 1С. И о чем они там перешептываются, похоже, скоро уже не будет знать никто. А на страже склада стоит чудесный алгоритм под названием «контроль отрицательных остатков» (плохо, правда, стоит, но это тема отдельного разговора). Человеку же остается всего лишь незавидная роль оператора по вводу данных. Да и то, пока. Совсем скоро программы окончательно научатся обмениваться данными без участия людей-операторов, и будет у нас самый настоящий и повсеместный «скайнет».
Нельзя сказать, что такого рода разговоры совсем оторваны от реальности, но в основе их все-таки лежит невежество. Технологии не портят жизнь людям. Да, они ее меняют. И, да, заставляют учиться новому. Но эта новая жизнь безусловно лучше старой. Технологии не ограничивают людей, а напротив, дают им новые, доселе невиданные возможности и способности. И я хочу показать это на одном, конкретном примере, связанном с учетом.
Представим себе человека и некоторую учетную систему. Для простоты, пусть это будет некий идеальный складской учет. Что-то на склад приходит, что-то уходит. Для каждой операции существует т.н. первичный документ. Данные первичных документов незамедлительно вводятся в базу. Задача человека организовать рациональный контроль за процессом, с целью не допустить расхождения между первичными документами и данными в учетной системе.
Человек принимает решение сверять каждый первичный документ с данными в системе. Но тут возникает проблема. Дело в том, что нельзя просто один раз сверить конкретный документ с данными системы. Потом отложить этот документ в сторону и забыть о нем навсегда. Данные в системе могут измениться и это потребует повторной сверки. А самое печальное заключается в том, что тот, кто изменил данные не обязательно будет гореть желанием сообщить вам об этом. Напротив, в его интересах будет, чтобы никто никогда не узнал об изменении. Например, некто меняет в приходном документе "110 штук по цене 101 рубль" на "101 штука по цене 110 рублей". Присваивает себе 9 штук. И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят. Вы можете создать сколь угодно изощренную систему прав доступа. И не менее изощренную систему логирования изменений. Результатом ваших усилий будет всего лишь возросшее у вас же чувство уверенности. И это ровно то, что полностью устраивает того, кто увел у вас 9 штук. Это хорошо, скажет он себе, что они так уверены. Пусть и дальше будут уверены так же. Или еще сильнее. Надо им еще пару идей подкинуть. Нет никакого другого способа отследить изменения, кроме как производить каждый раз сверку абсолютно всех документов. Раньше такое решение даже и не приходило никому в голову. Или, по крайней мере, не задерживалось там дольше микросекунд. Это представлялось очевидно невозможным. Но... как совершенно верно подметил один русский поэт: невозможное возможно.
Допустим, все только начинается. Прошли несколько операций на складе. У человека есть несколько первичных документов, а в базе есть соответствующие им записи. Человек сверяет каждый документ с данными в базе и попутно проделывает следующее (чтобы текст был понятен непрограммистам, я воспользуюсь неким псевдоязыком программирования):
для каждого документа из документов в базе
превратим данные документа в строку
добавим к ней предыдущий ключ/хеш
получим новый ключ/хеш для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец
В этих шести строчках описана технология блокчейн в чистом виде. Под получением ключа/хеша подразумевается вычисление какой-либо хеш-функции, например SHA256. Сразу надо отметить, что человек может вести журнал в той же самой базе. Как мы уже говорили, данные в базе могут изменить. В том числе могут изменить сам журнал. Но человека это не волнует. Потому что, как вы увидите дальше, изменить журнал незаметно для человека не получится.
Вернемся к процессу. Первая порция документов сверена и занесена в журнал. Далее происходит самое важное действие. Человек переписывает последний ключ в какое-нибудь секретное место (например на бумагу, это будет самый надежный вариант; если использовать SHA256, это займет не более 2 минут, я проверял). Теперь сеанс сверки можно считать завершенным.
Через некоторое время на складе происходит еще какое-то количество событий и появляются новые первичные документы.
Человек приступает к следующему сеансу. Первым делом он сверяет последний ключ в журнале с тем, что у него хранится в секретном месте. Здесь происходит самое интересное. Сверяя некоторое, не очень большое, количество символов, человек визуально контролирует неограниченный объем данных. Убедившись в том, что ключи совпадают, человек далее проделывает следующее:
для каждой записи из журнала
получим данные документа по ссылке и превратим их в строку
добавим к ней значение ключа из предыдущей записи
получим значение ключа для этой составной строки
сравним его с ключом, который записан в журнале
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
превратим данные документа в строку
добавим к ней предыдущий ключ
получим новый ключ для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец
Мы убедились, что документы, внесенные в журнал, не изменялись. После чего добавили в журнал новую порцию документов, попутно сверяя каждый с первичным документом. Теперь осталось определиться с тем, что делать, когда обнаруживается изменение ранее введенного в систему документа. В принципе, это нормальный рабочий момент. Время от времени он имеет место быть. Поэтому, человек принимает следующее решение. При обнаружении изменения, делать повторную сверку с первичным документом, старую запись в журнале оставлять как есть, а в конец журнала добавлять новую запись. В старой записи указывать ссылку на новую, как на потомка. А в новой указывать ссылку на старую, как на предка. И, наконец, использовать указатель на предка при формировании ключа. Список действий в окончательном виде выглядит так:
для каждой записи из журнала
если запись не имеет потомка
получим данные документа по ссылке и превратим их в строку
добавим к ней значение ключа из предыдущей записи
добавим значение указателя на предка
получим значение ключа для этой составной строки
если вычисленный ключ не равен ключу в журнале
запишем в журнал новую запись с указанием предка
в старой записи дадим указание на потомка
конец
конец
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
превратим данные документа в строку
добавим к ней предыдущий ключ
получим новый ключ для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец
Разумеется, все это делается не в ручном режиме. Все действия, за исключением собственно сверки с первичными документами, выполняются программой, которая запускается при каждом сеансе контроля. Описанная здесь система представляет собой абсолютное "всевидящее око". Любое добавление или изменение будет обнаружено с помощью журнала. После чего правомерность операции может быть подтверждена путем сверки с первичным документом. В свою очередь сам журнал защищен от подмены технологией блокчейн и записью последнего ключа в секретное место.
Единственная теоретически возможная атака заключается в подмене программы. Действительно, есть такая максима, гласящая, что абсолютно доверять можно только той программе, которую написал сам. На самом деле, ее следовало бы перефразировать так: абсолютно доверять можно только той программе, которую ты прочитал сам непосредственно перед запуском. Представленная здесь программа настолько проста, что вполне удовлетворяет этому условию. В этих 19 строках просто негде спрятать закладку.
Поэтому программу можно контролировать визуально. Впрочем, существуют еще и достаточно надежные способы контроля, основанные также на вычислении хеш-функции и сравнении результатов.
Используя эту, в общем не хитрую технологию, человек получает способность контролировать любые объемы данных. Причем, результат будет эквивалентен тому, который получился бы при сверке абсолютно всех документов в каждом сеансе контроля. Это дает возможность создавать абсолютно надежные системы контроля. В свою очередь, от человека требуется совсем не много. Всего лишь освоить тот или иной способ контроля над запускаемыми программами.
На этом простом примере я хотел показать, что технологии могут и должны быть гуманными. Не ограничивать человека, а напротив, открывать ему новые горизонты. Конечно, контроль данных - тема хотя и важная, но это далеко не все, что есть в учете. Я уверен, будут (или даже уже есть) и другие технологии, расширяющие возможности человека в области учета. Учет, как институт защиты интересов участников бизнеса, конечно же не умер. Просто он становится другим. Лучше и надежнее. При этом роль человека не уменьшается, а наоборот, по мере того, как растут возможности человека, растет и его роль в процессе.
