Учет, как особый, достаточно сложный и уважаемый вид человеческой деятельности действительно умер. Навсегда ушли те времена, когда человек, нашедший в себе силы освоить премудрости дебета и кредита, сразу становился обладателем магических перков. Он мог разговаривать с налоговой и следить за тем, чтобы не разворовали склад. При том, что не стоял день и ночь рядом со складом с ружьем, а использовал магию цифр, сидя в комфортном кабинете. Теперь с налоговой разговаривает программа 1С. И о чем они там перешептываются, похоже, скоро уже не будет знать никто. А на страже склада стоит чудесный алгоритм под названием «контроль отрицательных остатков» (плохо, правда, стоит, но это тема отдельного разговора). Человеку же остается всего лишь незавидная роль оператора по вводу данных. Да и то, пока. Совсем скоро программы окончательно научатся обмениваться данными без участия людей-операторов, и будет у нас самый настоящий и повсеместный «скайнет».

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

Представим себе человека и некоторую учетную систему. Для простоты, пусть это будет некий идеальный складской учет. Что-то на склад приходит, что-то уходит. Для каждой операции существует т.н. первичный документ. Данные первичных документов незамедлительно вводятся в базу. Задача человека организовать рациональный контроль за процессом, с целью не допустить расхождения между первичными документами и данными в учетной системе.
Человек принимает решение сверять каждый первичный документ с данными в системе. Но тут возникает проблема. Дело в том, что нельзя просто один раз сверить конкретный документ с данными системы. Потом отложить этот документ в сторону и забыть о нем навсегда. Данные в системе могут измениться и это потребует повторной сверки. А самое печальное заключается в том, что тот, кто изменил данные не обязательно будет гореть желанием сообщить вам об этом. Напротив, в его интересах будет чтобы никто никогда не узнал об изменении. Например, некто меняет в приходном документе "110 штук по цене 101 рубль" на "101 штука по цене 110 рублей". Присваивает себе 9 штук. И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят. Вы можете создать сколь угодно изощренную систему прав доступа. И не менее изощренную систему логирования изменений. Результатом ваших усилий будет всего лишь возросшее у вас же чувство уверенности. И это ровно то, что полностью устраивает того, кто увел у вас 9 штук. Это хорошо, скажет он себе, что они так уверены. Пусть и дальше будут уверены та�� же. Или еще сильнее. Надо им еще пару идей подкинуть. Нет никакого другого способа отследить изменения, кроме как производить каждый раз сверку абсолютно всех документов. Раньше такое решение даже и не приходило никому в голову. Или, по крайней мере, не задерживалось там дольше микросекунд. Это представлялось очевидно невозможным. Но... как совершенно верно подметил один русский поэт: невозможное возможно.

Допустим, все только начинается. Прошли несколько операций на складе. У человека есть несколько первичных документов, а в базе есть соответствующие им записи. Человек сверяет каждый документ с данными в базе и попутно проделывает следующее (чтобы текст был понятен непрограммистам, я воспользуюсь неким псевдоязыком программирования):

для каждого документа из документов в базе
 превратим данные документа в строку
добавим к ней предыдущий ключ/хеш
получим новый ключ/хеш для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец

В этих шести строчках описана технология блокчейн в чистом виде. Под получением ключа/хеша подразумевается вычисление какой-либо хеш-функции, например SHA256. Сразу надо отметить, что человек может вести журнал в той же самой базе. Как мы уже говорили, данные в базе могут изменить. В том числе могут изменить сам журнал. Но человека это не волнует. Потому что, как вы увидите дальше, изменить журнал незаметно для человека не получится.

Вернемся к процессу. Первая порция документов сверена и занесена в журнал. Далее происходит самое важное действие. Человек переписывает последний ключ в какое-нибудь секретное место (например на бумагу, это будет самый надежный вариант; если использовать SHA256, это займет не более 2 минут, я проверял). Теперь сеанс сверки можно считать завершенным.

Через некоторое время на складе происходит еще какое-то количество событий и появляются новые первичные документы. Человек приступает к следующему сеансу. Первым делом он сверяет последний ключ в журнале с тем, что у него хранится в секретном месте. Здесь происходит самое интересное. Сверяя некоторое, не очень большое, количество символов, человек визуально контролирует неограниченный объем данных. Убедившись в том, что ключи совпадают, человек далее проделывает следующее:

для каждой записи из журнала
получим данные документа по ссылке и превратим их в строку
добавим к ней значение ключа из предыдущей записи
получим значение ключа для этой составной строки
сравним его с ключом, который записан в журнале
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
превратим данные документа в строку
добавим к ней предыдущий ключ
получим новый ключ для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец

Мы убедились, что документы внесенные в журнал не изменялись. После чего добавили в журнал новую порцию документов, попутно сверяя каждый с первичным документом. Теперь осталось определиться с тем, что делать когда обнаруживается изменение ранее введенного в систему документа. В принципе, это нормальный рабочий момент. Время от времени он имеет место быть. Поэтому, человек принимает следующее решение. При обнаружении изменения, делать повторную сверку с первичным документом, старую запись в журнале оставлять как есть, а в конец журнала добавлять новую запись. В старой записи указывать ссылку на новую, как на потомка. А в новой указывать ссылку на старую, как на предка. И, наконец, использовать указатель на предка при формировании ключа. Список действий в окончательном виде выглядит так:

для каждой записи из журнала
если запись не имеет потомка
получим данные документа по ссылке и превратим их в строку
добавим к ней значение ключа из предыдущей записи
добавим значение указателя на предка
получим значение ключа для этой составной строки
если вычисленный ключ не равен ключу в журнале
запишем в журнал новую запись с указанием предка
в старой записи дадим указание на потомка
конец
конец
конец
получим список новых документов (это те, что есть в базе, но нет в журнале)
для каждого документа из новых документов
превратим данные документа в строку
добавим к ней предыдущий ключ
получим новый ключ для этой составной строки
запишем в журнал ссылку на документ и новый ключ
конец

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

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

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

На этом простом примере я хотел показать, что технологии могут и должны быть гуманными. Не ограничивать человека, а напротив, открывать ему новые горизонты. Конечно, контроль данных - тема хотя и важная, но это далеко не все, что есть в учете. Я уверен, будут (или даже уже есть) и другие технологии, расширяющие возможности человека в области учета. Учет, как институт защиты интересов участников бизнеса, конечно же не умер. Просто он становится другим. Лучше и надежнее. При этом роль человека не уменьшается, а наоборот, по мере того, как растут возможности человека, растет и его роль в процессе.