Модуль 2.
- Сопоставление ТМА с существующими в текущей практике инструментами, методами и технологиями.
- ИТ и учет.
Урок. К1.М2.0005. В чем разница по технологиям учета.
Видео формат урока
Аудио формат урока (подкаст)
Текстовый формат урока
В первом модуле обучения мы детально разобрали то, какая должна быть основа в управленческом учете, что должно быть ядром результата процесса ведения управленческого учета.
К сожалению, нам придется потратить еще время на глубокий анализ текущей ситуации в современной практике учета. В этом модуле мы будем рассматривать проблемы текущей практики и сопоставлять популярные методы с тем, что предлагается в ТМА.
Если в первом модуле мы утвердились с тем, какая должна быть основа для управленческого учета, то в этом модуле мы заложим базовые технологические и методологические принципы.
Поехали!
На практике финансовые управленческие отчеты формируют двумя путями:
-
Наколенно-прикладным. Используем Excel или Google таблицы.
-
С использованием системы счетоводства (бухгалтерии)
Я не устану повторять, что если речь идет о триаде финансовых отчетов, то любые варианты собирать их вручную, с использованием таблиц Excel, надергивая данные из разных источников, не являются системными и не могут рассматриваться, как нормальный инструментарий для практики. То, что так делают повсеместно, не доказывает, что это правильно или даже удовлетворительно, а должно заставлять задуматься над вопросом: ПОЧЕМУ? Ответ ищите в том, что системы счетоводства отстают от развития требований управления в современном бизнесе.
Причина в отставании развития счетоводных систем – это глубокая стандартизация, причем без особого учета интересов владельцев бизнеса и менеджмента. А соответственно существует неудовлетворенность по результатам для целей управления и контроля со стороны собственников и руководства бизнеса.
Наколенно-прикладной подход в какой-то степени решает задачи управленческого учета, но влечет за собой множество негативных побочных явлений. На дистанции эти негативные явления полностью уничтожают результат. А время и деньги, потраченные на развитие наколенно-прикладной системы, будут потеряны. Если бизнес масштабируется, то скрытых потерь, косвенно связанных с некачественным учетом будет очень много.
Разрабатывая ТМА, мы концентрировали внимание на системном подходе и реновировали саму счетоводную систему. Поэтому в том курсе первый вариант наколенно-прикладного решения задачи формирования финансовых управленческих отчетов мы никак не рассматриваем и не сравниваем.
Наша задача понять, что в классических счетоводных системах не так и почему их результат не удовлетворяет целям управления, безотносительно каких-либо стандартов.
Далее мы сравниваем ТМА технологии с технологиями классического счетоводства, которые используются повсеместно во всех бухгалтерских и ERP системах в виде модуля финансового учета, наших или забугорных, без разницы.
Итак, мы рассматриваем систему счетоводства - это бухгалтерский учет в основе своей и безотносительно стандартов и типов потребителя:
Для большинства людей, занимающихся бизнесом, система счетоводства – это непонятные слова или черный ящик. Для большинства людей слово Бухгалтерия отождествляется со стандартами, сложностью, непонятностью и тем, что это для государства. Но, как всегда, в основе всего сложного лежать довольно простые базовые принципы. Для того, чтобы адекватно сравнить технологии необходимо понять эти простые базовые принципы.
Возможно, сейчас кто-то подумал: "Зачем мне это? Я просто хочу научиться пользоваться системой. Зачем мне понимать базовые основы бухгалтерского учета?"
Отвечу. Чтобы было все просто! Знание и понимание основ делает любую сложную многофункциональную систему для вас простой и понятной. В любой адекватной, хоть и сложной, многофункциональной системе всегда лежат очень простые базовые принципы. Поняв эти принципы, вся система становится понятной. Гораздо сложнее пытаться запомнить и освоить работу всех функций, не понимая самих основ.
Небольшое отступление. Есть принципы работы системы, а есть условности. Это разные вещи. Условности надо запомнить и знать, а принципы надо понять.
Учитываемые события в бизнесе всегда имеют две стороны. Например, мы отгрузили товар. С одной стороны у нас убыло товара, но с другой прибыло в задолженности покупателя перед нами.
Или, мы получили деньги за ранее отгруженный товар. С одной стороны у нас прибыло в деньгах, а с другой убыло в задолженности покупателя перед нами.
Это не бухгалтеры придумали, а это обычная природа вещей (вот это принцип, а не условность). Если где-то что-то убывает, значит где-то что-то прибывает. Бухгалтеры обнаружили это свойство событий более пяти веков назад и у себя в системе назвали это принципом двойной записи. Чтобы учесть событие достоверно, нужно учесть обе стороны, а значить нужно записать два раза.
Для большинства слушателей курса учет в виде первичных документов типа накладной на отгрузку или поступление товаров это и есть учет. Что происходит с данными дальше не очень понятно, но в отчетах мы видим сводную информацию по остаткам и оборотам. Для большинства специалистов очевидно, что если на уровне первичных документов добиться полного учета, то собрать любые отчеты не будет больших проблем, ведь мы используем компьютеры, которые умеют быстро считать. Но все не совсем так, особенно если речь идет о триаде финансовых отчетов. Нужна система! Такой системой является счетоводство. Чтобы получить на выходе информацию об остатках и оборотах, каждый первичный документ проводится в счетоводной системе.
Документы могут быть разными, но в счетоводной системе данные о событиях, или как говорят бухгалтеры, о хозяйственных операциях, структурируются строго определенным образом.
Каждый первичный документ – это удобное на операционном уровне средство учета и может содержать информацию о нескольких событиях. Например, в моем автосервисе еще в 1998-мом году был документ «Наряд-заказ». Я лично в Excel разработал его печатную форму, которую заполняли на каждый автомобиль в работе. Мой автосервис не просто занимался ремонтом, а продавал и устанавливал дополнительное оборудование (автосигнализации, автозвук, тюнинг) и попутно производил ремонт электрики. Это был бумажный документ, данные из которого каждый день заносились в систему «Коммерсант-СМ». в этой системе было всего три сущности: Деньги; Товары; Услуги. По каждой сущности можно было оформить поступление или выбытие. Фактически это было шесть типовых событий, которыми можно было описать любые происходящие события. В наряд-заказе их было много:
-
Был продан товар – это расход товаров. Списывался товар, начислялась прибыль по наценке, возникала задолженность клиента.
-
Была произведена установка или ремонт – это расход услуги. Начислялась прибыль по услугам, возникала задолженность клиента.
-
Были получены деньги от клиента – это приход денег. Списывалась задолженность клиента приходовались деньги.
-
Была начислена заработная плата сдельно – это приход услуги. Начислялись расходы и возникала наша задолженность перед сотрудником.
-
Были начислены комиссионные продавцу – это приход услуги. Начислялись расходы и возникала наша задолженность перед сотрудником.
Так каждый наряд-заказ заносился в систему в виде пяти типовых событий. Делалось это тогда вручную.
Обратите внимание. Был сделан удобный для операционной работы бумажный документ. Все сделано было так, чтобы сотруднику было удобно делать записи походу обслуживания клиентов. Потом отдельный сотрудник интерпретировал данные этого документа в описанной выше системе шести типовых операций. На выходе я получал текущую информацию об остатках и оборотах. Расчетные остатки денег, товаров, взаиморасчетов. Расчетные обороты по доходам и расходам и движению денежных средств.
Можно сказать, что Коммерсант-СМ был простой, но полноценной счетоводной системой. Но, к сожалению, он не был лишен недостатков больших и сложных стандартизированных счетоводных систем, о которых речь пойдет ниже.
Я осознанно привел в пример систематику, которая была заложена в Коммерсант-СМ. Этой системы уже подавно не существует, но именно ее простота в части полноценного учета по принципу двойной записи дала мне лично осознание того, что нужно и что должно быть. Если бы я сейчас объяснил бы этот базовый принцип на общепринятой бухгалтерии с планом счетов и кучей условностей, то понять это было бы гораздо сложнее.
Надеюсь, что сейчас сама идея понятна. Есть удобная для повседневной работы первичка (первичные документы), данные из которых должны быть структурированы в счетоводной системе. Сейчас это происходит автоматизировано, поэтому большинство даже бухгалтеров не особо знают все тонкости этого структурирования данных.
Факт, что на выходе мы получаем информацию в виде финансовых отчетов.
Может возникнуть вопрос, почему нельзя собрать триаду финансовых отчетов прямо из первичных документов?
Можно, но это будет еще сложнее. По определению первичные документы служат для удобства в повседневной деятельности. То, как я создал удобный бланк наряд-заказа у себя в сервисе. В других сервисах используют другой удобный или не очень документ. В каждом отдельном бизнесе удобства будут разными и документы лучше делать разными. Про это мы будем говорить позднее. Универсальные документы всегда сложны для повседневной практики, поскольку в них разработчики пытаются учесть практику множества различных предприятий. Это все равно, если бы я для своего автосервиса взял бы какую-нибудь форму из общероссийского классификатора управленческой документации, например, ОК-011-93.
Зайдите сейчас в поисковик, наберите запрос «форма наряд-заказа». Вы увидите великое множество вариантов этих форм. Почему? Потому что всем удобно по-разному.
Для того, чтобы формировать управленческую триаду финансовых отчетов из документов, нужно каждый этот документ разбирать по структуре разрезов учета.
Чтобы лучше понять, применю аналогию.
Представьте логистику доставки грузов. Из города А большая фура везет сборный груз в город Б. Груз должен быть доставлен в 1000 разных адресов. Никто не направляет фуру по этим 1000 адресов, а строят на въезде в город большой логистический терминал. Туда большая фура разгружается. Все товары раскладываются по полочкам системно. До адресатов этот груз уже развозится небольшими автомобилями.
Так и тут, надо данные о событиях из первичных документов разложить по полочкам, чтобы при необходимости использовать для составления отчета и анализа. В аналогии - это как построить большой логистический центр для всех поступающих из первичных документов данных, с которым будет удобно работать, когда эти данные понадобится отгружать в отчеты. Этот логистический центр и есть база счетов учета в счетоводной системе.
Как технологически устроены счетоводные системы?
За всей напыщенной сложностью бухгалтерского учета стоит довольно простая конструкция.
Как уже говорилось, в основе лежит принцип двойной записи. Каждое событие имеет две стороны, поэтому оно отражается двумя записями в системе. Каждая бухгалтерская книга (счет учета) формирует свой аналитический разрез. Например, в одной книге вы ведете учет денег, в другой учет материалов, в третьей взаиморасчеты с клиентами. Я объясню это с использованием таблицы Excel, а вы на практическом задании попробуйте сделать тоже самое.
Один лист Excel я назову «Деньги», другой «Ценности, Третий «Взаиморасчеты»; четвертый «ДР» (доходы/расходы).
Каждая запись на всех листах будет иметь одинаковые поля: дата; комментарий; приход (Дт); расходы (Кт); остаток. Приход в бухгалтерии называют дебет (Дт), расход – кредит (Кт), а остаток - сальдо.
Сейчас мы начнем вести учет на основании каких-то простых первичных документов.
Но для начала я покажу один прикол. В счете «ДР» расходы – это положительные значения, а доходы – отрицательные. Забегая вперед, это необходимо объяснить.
Наше предприятие существует в балансе:
Деньги + Ценности + Взаиморасчеты (+Нам должны – Мы должны) = Прибыль (Доходы – расходы)
Примечание! В этой формуле Прибыль - это накопленная прибыль, т.е. все доходы и все расходы с самого начала до какого-то момента времени. По сути это собственный капитал или, как говорят на профессиональном языке, чистые активы.
Это очень просто. Например, изначально, у меня нет ничего. Я оказал услугу и мне за это заплатили 1000 рублей. У меня появилось 1000 рублей с одной стороны уравнения в деньгах и 1000 рублей с другой стороны в прибыли. Понятно?
Но учет мы ведем с одной стороны – со стороны бизнеса. Поэтому в уравнении Прибыль надо перенести на левую сторону:
Деньги + Ценности + Взаиморасчеты – Прибыль = 0
Прибыль = Доходы – расходы , а -Прибыль = Расходы – Доходы
Понятно?
Поэтому в методологии ТМА срез доходов и расходов называется «Убыток», а не Прибыль, но про это все будем говорить подробно в следующих модулях обучения. Сейчас нам нужно просто посмотреть, как работает классическая бухгалтерия.
Для начала в наши таблицы надо ввести какие-то начальные остатки. Например, у меня есть товар1 в каком-то количестве, на общую сумму 1000 рублей, и он полностью принадлежит мне. Вспоминаем, что каждая запись должна делаться дважды, потому что в жизни каждое событие имеет две стороны.
С одной стороны запишем товары в приход, а с другой мы запишем наш прошлый доход со знаком минус (пришло/ушло, т.е. ушло расходов).
На счете ценности у нас +1000, а на счете ДР -1000. В сумме дает ноль. Наверное, теперь понятие сбалансированности учета будет еще понятнее. 😊 Я добавил лист, где формулой сводится этот баланс.
Теперь продадим этот товар с отсрочкой платежа.
Мы оформили накладную на отгрузку всего товара с наценкой на общую сумму 1500 рублей. И тут не одно событие, а два.
Первое событие заключено в том, что с одной стороны мы сформировали выручку на 1500, с другой – у нас появилась задолженность Покупателя1 перед нами на сумму 1500 рублей. Второе событие заключено в том, что у нас произошла прибыль. С одной стороны у нас уходит товар на 1000 рублей, а с другой у нас прибывает расходов (себестоимость). Себестоимость товара – это ведь наши расходы!
Положительные взаиморасчеты плюс отрицательные расходы – это Выручка. Возможно, кому-то покажется, что мозги взрываются, но это действительно очень просто, хотя немного необычно звучит. А главное, что это все реально как в жизни.
Не забываем, что расходы положительные, а доходы отрицательные, потому что балансовое уравнение мы приравняли к нулю. Это математика пятый класс.
У нас произошло списание товаров на 1000 рублей, с одной стороны, и мы понесли расходы по статье Себестоимость тоже на 1000 рублей.
Наш баланс сохранился и показывает нам, что наше финансовое состояние - это 1500 рублей нам должен покупатель, и 1500 у нас в общей сложности в прибыли. Таким образом, данное событие нам принесло прибавку к прибыли 500 рублей. Можно нас поздравить, мы растем! 😊
Но нам еще надо получить деньги с покупателя. Покупатель оказался честным и через 10 дней заплатил нам за полученный товар.
С одной стороны у нас прибавилось денег, а с другой убавилось задолженности.
Наш баланс изменился по структуре, но прибыли у нас никакой не появилось. Еще раз напомню, что в сбалансированной системе доходы отрицательные, а расходы положительные. Поэтому отрицательная цифра - 1500 означает полторы тысячи прибыли.
Как было 1500, так и осталось.
Вот вам на простой модели и принцип начисления и принцип двойной записи.
Все не так и сложно, как представляется бухгалтерией.
Люди, разбирающиеся в Excel, увидели, что на каждом листе можно делать отборы и, например посмотреть задолженность по Покупателю1 на ту или другую дату. А на отдельном листе можно собрать полноценный баланс, ОДР и ОДДС. Но не забегайте вперед. Это лишь модель классического счетоводства. Правда я ее разложил в балансовом уравнении ТМА (Деньги/Ценности/Долги/Убыток). В классической бухгалтерии все гораздо сложнее за счет сотен и тысяч условностей, описанных в правилах и стандартах. По жизни все гораздо проще.
В чем технологический недостаток классической модели?
Обратите внимание, что мы учли ценности на общую сумму 1000 рублей. Я даже не сказал какое количество было и по какой стоимости. Мы прекрасно понимаем, что ценности сегодня стоят так, завтра иначе. На складе у нас лежат не деньги, а ценности в определенном количестве. И эти ценности на разные даты могут иметь разные стоимости. Впрочем также, как и деньги, если они у нас лежать в отличной от учетной валюте. Деньги даже нагляднее, поскольку проблему учета и расчета курсовых разниц знают многие в реальной практике.
Дело в том, что в итоговых отчетах (триаде финансовых отчетов) все данные должны быть представлены в едином денежном (финансовом) выражении. Поэтому эти отчеты и называются Финансовыми.
При учете на бумаге, для формирования финансовых отчетов нужно было вести учет также в финансовом выражении. Иначе при составлении отчетов, нам бы пришлось каждую позицию пересчитывать, умножая количество на текущую стоимость. Вручную это практически невозможно. Так модель счетоводной системы устоялась в виде ведения учета в финансовом выражении, т.е. записи данных о событиях производится сразу в финансовом выражении. Фактически перед записью происходит процесс оценки.
Все бы ничего, но стоимости по жизни меняются, а в базе учета записи пересчитанные на момент занесения операций. Таким образом, эти данные при внешнем изменении стоимости по факту не верны.
В нашем примере есть 10 единиц товара по 100 рублей. Это было 01 января. Представьте, что через неделю стоимость этого товара выросла до130 рублей. Получится, что у нас не 1000 рублей товара, а 1300. А 300 рублей - это прибыль, возникшая в результате внешнего изменения стоимости , а не от того, что мы произвели какое-то действие. Это полная аналогия с курсовыми разницами, которые по факту являются частным случаем доходов и расходов, связанных со стоимостными колебаниями.
Так, что если вы не имеете дела с валютами не считайте, что проблемы классического счетоводства вас не касаются.
Ключевым недостатком классических систем счетоводства является то, что они не учитывают доходы и расходы от стоимостных колебаний. Официально недостаток формулируется, как неспособность учитывать инфляцию.
И тут знающие люди в голове сразу начинают со мной спорить. Ведь на практике просто вводится начисление курсовой или стоимостной разницы и происходит учет как раз этого дохода расхода, а система начинает отражать корректные данные.
Но не торопитесь. Это не система учитывает, а вы (или программный модуль), вводя эти корректирующие операции. И это не все. Во второй части этого модуля мы будем говорить о неприемлемости учета и записи вторичных данных. Формат начисления корректирующих операций – это учет и запись вторичных данных (данные, которые рассчитываются на основе уже имеющихся в базе первичных, в данном случае это количество и стоимость).
Сейчас мы рассматриваем самый вопиющий случай, когда старые привычки тормозят прогресс. Ведь учет велся в финансовом выражении только по причине того, что невозможно при формировании финансовых отчетов производить множество операций приведения количественных данных (в натуральном выражении) в денежное выражение вручную. Т. е. перемножать количество на стоимость.
Но ведь сейчас мы ведем учет не на бумаге.
Мой ноутбук, на котором я пишу этот урок в данный момент, способен производить миллиарды математических расчетов в секунду. Значит теперь мы можем производить операции приведения данных в финансовое выражение в момент формирования отчетов, а учет вести в натуральном выражении!
Что и было сделано в ТМА.
Это одно из двух ключевых изменений устройства счетоводной системы, описанных в патенте на изобретение.
Чтобы объяснить всю суть прорыва, надо объяснить в чем заключается второе изменение и наконец от теории приступить к практике, т. е. перейти от технологической к методологической части, а уже потом к инструментарию.
Второе изменение в большей степени теоретической, но понять и принять его как принцип не помешает.
Как я писал уже ранее в жизни всегда существует баланс, поэтому в полноценном учете в цифрах тоже должен быть баланс, если эти цифры отражают действительное положение вещей. Так принцип двойной записи в исходном представлении полностью обеспечивает сбалансированность цифр в учете, как в жизни. Но мы только что изменили устройство системы и стали вести учет операций не в финансовом, а в натуральном выражении, что полностью нарушает баланс цифр.
Например, вы берете кредит у банка. Договор на 1000 долларов, а банк переводит вам на счет 65 000 рублей по текущему курсу ЦБ.
Мы так и запишем в ТМА. С одной стороны у нас пришло 65 000 рублей, а с другой у нас появился долг 1000 долларов. При формировании баланса в рублях 1000 долларов будет умножена на текущую стоимость 65 и в отчете будет 65 000 рублей.
В учете нет баланса, хотя если мы смотрим на цифры через призму базы стоимостей, то есть. Тут спорный вопрос. В принципе этого было бы достаточно, но мы в теории ТМА изменили принцип записи данных. Мы ввели в систему учета балансирующий разрез учета. Методологически он назван ДОЦ (дельты относительных ценностей), или проще ПЕРЕОЦЕНКИ.
Запись операции в базу будет происходить следующим образом. На Деньгах прибудет 65 000 и та же сумма убудет в ДОЦ, на Взаиморасчетах убудет 1000 долларов и та же сумма прибудет на ДОЦ. Таким образом все цифры в учете стали сбалансированными, а мы получили еще один очень важный результат.
Если ДОЦ перемножить на все стоимости, т. е. привести его в единое финансовое выражение, то мы получим общую стоимостную дельту. Другими, простыми, словами мы получим общую прибыль или убыток, связанный с внешними изменениями стоимостей и курсов валют.
Мы уже говорили, что в классических системах счетоводства есть недостаток. Они не умеют учитывать изменения стоимости во времени. Для учета таких изменений надо вводить корректирующие операции, что в свою очередь делает учет периодическим. Невозможно учитывать колебания стоимости вводом корректирующих операций, если эти колебания могут происходить ежеминутно. В итоге, как уже писал, корректирующая операция рассчитывается на основе уже записанных в базу первичных данных, т. е. является вторичными данными. Если вторичные данные рассчитываются и записываются в базу, то возникает проблема поддержания целостности данных. Надо контролировать изменения первичных данных, связанных с полученными вторичными, а при изменении пересчитывать и перезаписывать вторичные.
На примере будет проще понять. Курсовая разница – это даже не вторичные, а третичные данные. Предположим, что курс доллара изменился на следующий день и стал 66. Соответственно с одной стороны наш долг в рублевом исчислении вырос до 66 000 рублей, а с другой мы понесли убыток 1000 рублей, связанный с этим изменением курса. Это и есть курсовая разница, как ее принято называть. Чтобы ее посчитать, нам надо сначала 1000 долларов привести в рубли два раза на каждый день, а потом из второй полученной суммы вычесть первую. В общем и целом, операция простая и расчет курсовых разниц обычно в компьютерных системах не делается вручную, а их считает программа. Но посмотрите, что может произойти, если эту курсовую разницу записывать в базу в учет, как это делается в классическом счетоводстве.
Представьте, что операция была внесена ошибочно. Оператор ошибся, в действительности мы получили не 1000 долларов, а 10 000 долларов. У нас в учете уже записана расчетная задолженность банку 65 000 рублей и корректирующая курсовая разница 1000 рублей. Обе эти цифры посчитаны исходя из 1000 долларов. Ошибку мы обнаружили позднее, когда увидели в балансе слишком маленькую цифру кредита. Изменений курсов было уже много, соответственно корректирующих операций занесено уже много. Специалист по учету исправляет сумму кредита на 650 000 рублей. А курсовые разницы при этом остались прежними, рассчитанными на основе ошибочно внесенных первичных данных. Это надо понять, вспомнить, и каждую курсовую заново рассчитать и заново записать в базу. Для программиста, который будет разрабатывать эту программу нужно будет как-то связывать курсовые разницы с исходными данными и контролировать их изменения, иначе система будет сильно зависеть от человеческого фактора. Это реальная головная боль, поэтому проще «закрыть» период от изменений и не парится, установив условные правила, что все корректировки вносятся в текущем периоде (про это мы еще будем говорить, насколько это неправильно).
Официально этот недостаток называют, как неспособность системы на основе двойной записи учитывать инфляционные процессы.
Как видите на скриншоте из википедии, все описанное выше правда. Вроде бы есть недостаток и даже проблема, но она «вполне решается….». Только вот это решение имеет ряд побочных явлений, которые я уже описал, что в свою очередь рождает десятки и сотни проблем на поверхности повседневной практики.
Два ключевых изменения в системе счетоводства, описанных выше и в патенте на изобретение, в ТМА решают эту проблему в корне. Пользователь может не знать, о процессах, происходящих внутри системы счетоводства ТМА, но он получает курсовые и стоимостные разницы в любой момент в отчетах. Они всегда правильные и зависят от того, в какой валюте вы эти отчеты смотрите.
Классическая система счетоводства может формировать отчеты только в установленной валюте учета, поскольку в этой валюте ведется учет и только по этой валюте начисляются курсовые разницы. А ТМА может формировать финансовые отчеты в любой валюте, поскольку учет ведется в натуральном выражении. Соответственно курсовые будут зависеть от того, в какой валюте вы сформировали финансовый отчет.
Применительно к нашему примеру. Если вы сформируете отчет в рублях, то курсовая возникает на сумме кредита в 1000 долларов. Если вы отчет сформируете в долларах, то курсовая возникнет на остатках денежных средств 65 000 рублей. А если вы сформируете отчет в Евро, то курсовая разница будет и на деньгах и на кредите. Сумма ценности этой курсовой разницы будет одинаковой, а вот источник ее возникновения разный.
Изменения крайне просты, но фундаментальны. Сложность в понимании этих довольно простых изменений заключается в установленных правилах, стандартах и учениях. Поэтому приходится писать так много слов.
В этом уроке чуть больше 3500 слов, хотя суть можно объяснить в одном абзаце. Еще одно подтверждение того, насколько сильно влияют устои и привычки на наше восприятие. Нет ничего сильнее привычки. Поэтому любую оценку я предлагаю делать исключительно по критериям эффективности, как это делается при анализе технологий при рассмотрении заявки на изобретение. Ключевым критерием принятия решения о выдаче патента на изобретение является «Изобретательский уровень». Предложенные технологии проходят этот критерий, если доказано, что они решают задачу значительно ЭФФЕКТИВНЕЕ ранее известных технологий. Так описанные выше технологические изменения прошли эту проверку и доказали, что их применение дает значительный рост эффективности в процессе ведения финансового учета и формирования финансовой отчетности. А именно это требуется для нормального и полноценного применения счетоводной системы в целях управления и контроля в современном быстроизменяющемся бизнесе.
Урок. К1.М2.0006. В чем разница в методологии учета.
Теперь Вы знаете какие технологические изменения произведены в счетоводной системе при создании ТМА.
Эти изменения находятся на базовом уровне.
На основе технологий разрабатываются методы для практики. Например, с технологической точки зрения гвоздь можно забивать молотком, а можно гвоздезабивным пистолетом. Результат один, а технологии разные. Соответственно сам процесс происходит двумя разными методами. Один метод для забивания гвоздика молотком, и совсем другой для гвоздезабивного пистолета. Я лично недавно попробовал эту штуку. Это чума! Гвозди длиной 150мм входят полностью в сухое дерево, как в масло! Если применить метод забивания гвоздей молотком для гвоздезабивного пистолета, то получится смешно. Представьте меня с этим гвоздобоем в руке, забивающего большой гвоздь в доску, как молотком. 😊
Технологии - это лишь возможность, а вот методы и методологии - это уже ближе к практике, к которой мы так стремимся скорее прийти.
Сейчас всем понятно, что если мы внесли инновационные изменения в технологии на базовом уровне, то надо пересматривать все методы. Таким образом ТМА – это в основном новая методология.
Прошу НЕ пытайтесь прямо сейчас в деталях разобраться, как все работает. В данном уроке задача понять различия между классикой и ТМА. Причины и следствие. В последующих уроках мы будем подробно разбираться в деталях методологии ТМА и применения ее в реальной практике.
Когда я пришел учиться на бухгалтера по МСФО, то первое, что нам показали – это пять отдельных листочков, на каждом было написано по одному слову:
-
Активы
-
Обязательства
-
Капитал
-
Доходы
-
Расходы
Это основные разделы или разрезы учета в традиционной методологии. Еще они называются разделами плана счетов. В РСБУ разделы и нумерация установлена законодательно.
Есть хорошее выражение: Все новое – это хорошо забытое старое, которое отражает суть третьего закона диалектики. В далеком прошлом первый официальный план счетов имел четыре раздела:
-
Деньги
-
Ценности
-
Взаиморасчеты
-
Капитал
В ТМА, как Вы уже знаете четыре основных разреза учета:
-
Деньги
-
Ценности
-
Долги (Взаиморасчеты)
-
Убыток (= +Расходы – Доходы)
Разница с последним вариантом лишь в четвертом срезе. Мы считаем, что капитал - это очень условное понятие. Причем есть более заумный термин - Чистые активы.
Простите, не сдержался :).
В ТМА собственники бизнеса считаются такими же контрагентами, как и любые другие вокруг бизнеса, но в статусе собственника, который вкладывает и изымает ресурсы у бизнеса. Также у бизнеса в ходе работы появляется накопленный результат в виде накопленной прибыли или убытка. Поэтому при формировании условного капитала в балансе мы складываем сумму взаиморасчетов с собственником и накопленный результат деятельности. Позднее Вы поймете, насколько это естественно.
Как говорилось ранее ТМА создавалась без относительно каких-либо учений и правил в интересах собственников бизнеса и управления. Эти основные разделы возникли просто из здравого смысла, а в последствии утвердились по логике структуры более глубоких аналитических разрезов. Посудите сами. У денег свои аналитики: валюта; статья ДДС; место учета денег. У ценностей свои: наименование ценности; место учета ценностей. У взаиморасчетов свои: контрагент и договор, по которому он взаимодействует с нашим предприятием; статус, котором контрагент взаимодействует с нашим предприятием (покупатель, поставщик, сотрудник, кредитор, собственник и тд и тп). У доходов и расходов есть свои статьи доходов и расходов. Я перечислил базовые элементы, которые в каждом конкретном случае вполне могут быть расширены. Например, может быть статья движения ценностей, если для аналитики конкретного предприятия такое будет иметь значение. В расширенной версии ТМА есть общий разрез Время, про который мы будем говорить отдельно в дополнительном модуле обучения.
У меня есть личное мнение, почему возникли официальные разделы учета верхнего уровня, но обсуждать это мы не будем. Нам должно быть достаточно, что мы придерживаемся простого здравого смысла.
Что в классических методологиях счетоводство происходить дальше со структурой аналитических разрезов?
Следующий уровень – это план счетов.
Как Вы уже увидели на скриншоте с разделами, счетов может быть 100 и даже больше. Это просто разведение учета на более мелкие аналитики. Например, счет 51 – это деньги на расчетных счетах в банке, а счет 50 – это деньги в наличных кассах. Детализируя обороты и остатки по деньгам на эти счета, в бухгалтерии получают более подробную информацию.
Но всем понятно, что 100 позиций недостаточно для глубокой аналитики, поэтому возникают субсчета. Например, счет 62 - это взаиморасчеты с покупателями, но учитывают более детально. На счете 62.1 отражают возникновение задолженности покупателя при отгрузке товаров или оказании услуг, а на счете 62.2 учитывают суммы, оплаченные покупателем за полученные товары и услуги.
И этого недостаточно, поэтому у каждого счета и субсчета есть свои субконто (набор аналитический признаков).
Скажу Вам по секрету, что за непонятными словами типа дебет, кредит, субконто и т. д. скрывается действительная простота бухгалтерии. Субконто – это просто возможность повесить дополнительные признаки. Например, Субконто1 на счете 51 – это обычно конкретный расчетный счет, а Субконто2 на счете 51 – это статья движения денежных средств. Субконто 1 на счете 62 – это контрагент, а Субконто 2 на счете 62 – это договор контрагента.
У нас получается иерархическая вложенная структура:
- Разделы
- Счета
- Субсчета
- Субконто
Причем, уровень плана счетов в бухгалтерии называют синтетическим учета, а более детальный – аналитическим.
От куда это все взялось, блин?
Все от туда же, из времен бумажного учета!
Все счетоводные системы создавались в то время, когда базовый носитель информации был бумагой. Любые технологии дают определенные возможности и ограничения. Нужно было использовать уровень развития бумажных технологий так, чтобы максимально эффективно вести учет. Надо сказать, что бухгалтеры с этим великолепно справлялись.
К приходу новой парадигмы информационных технологий бухгалтерия стала наукой, а систематика и даже устройство системы стало закреплено законодательно. Поэтому общепринятая счетоводная система никак не могла быстро измениться. Она переехала на компьютеры, но осталась "бумажной".
Если во время технологических ограничений, на их основе возникают правила, то если технологические ограничения снимаются, то сами правила становятся ограничением.
И. Голдратт (ТОС)
Но если сегодня создавать бухгалтерию для собственника, которому она нужна не меньше, а больше, чем государству, то нас не сдерживают никакие стандарты и методы из времен, когда информационные технологии жили и развивались в бумажной парадигме.
В следующем уроке этого модуля мы будем подробно разбирать, как работать с данными и аналитикой с использованием компьютеров и баз данных, а пока показываю только результат.
Это базовая структура аналитических разрезов ТМА:
С естественной структурой аналитических разрезов и ее модификацией мы будем разбираться подробно в отдельном модуле обучения. Сейчас мы можем понять разницу, между условным делением и естественным делением. В классической методологии очень много условностей, установленных правилами, их надо знать, чтобы использовать всю систему. В ТМА более естественный порядок вещей. Он прост для понимания, а соответственно и не должно быть проблем при использовании системы в целом.
В классической методологии, которая была создана для бумажного учета имело значение выделить обобщенный уровень (то, что бухгалтеры называют синтетическим учетом), он давал возможность быстрее оценить ситуацию в целом, а также контролировать целостность на более детальном уровне аналитического учета. В компьютерном счетоводстве в этом нет никакого смысла. Мы можем получить одинаково быстро и общую картину и детальную. Поэтому смысла разбивать аналитику на уровне плана счетов нет никакого. Такое разбиение все усложняет. Чем больше счетов, тем больше вариантов корреспонденций между счетами (движение между счетами – это одна хозяйственная операция), тем больше условностей, тем сложнее.
В ТМА нет плана счетов, как такового. Нам вполне достаточно естественного разделения на четыре основных среза учета. Таким образом, мы получаем всего 16 вариантов типовых движений (корреспонденций между счетами). Это позволяет лучше понимать и интерпретировать в учет события. Вся общая и детальная аналитика взаимосвязана и жестко структурирована на уровне отчетов, бюджетов и детализации. Позднее мы будем подробно разбирать типовые движения.
Общая модель учета операций выглядит так:
Вы видите 10 разнонаправленных стрелок. Так им образом это 20 однонаправленных движения, четыре из которых из одного среза выходят и в него же и приходят. Получается всего 16 типовых движений.
Например. Вы купили автомобиль, сразу заплатили за него полную сумму. У вас пришло в Ценности и ушло из Денег (Плюс Ценности Минус Деньги). Вы купили автомобиль в рассрочку без первого взноса. У вас пришло в Ценностях и ушло в долгах (по контрагенту, у которого вы купили автомобиль образуется отрицательный долг, т. е. вы должны ему). Плюс Ценности Минус Долги.
Каждый срез, как мы уже говорили имеет свой, специфичный только для него, набор аналитик, поэтому каждое из движение запрашивает строго определенный набор аналитик. Например, «Плюс Ценности Минус Деньги» попросит указать Наименование ценности, место учета ценности, наименование валюты, место учета денег, статью движения денежных средств. Не забываем, что теперь мы не оцениваем в момент учета, а ведем учет актуальной стоимости (позднее мы подробно будем это разбирать).
Один мой знакомый ученый бухгалтер написал книгу, которая называется «Понимаете ли вы бухгалтерский учет?». В этой книге Михаил Медведев очень простым не академическим языком разбирает методологию ведения плана счетов классического счетоводства. Это самое краткое и самое понятное руководство, которое много раз мне помогало при освоении этой методологии целиком. Но это целая книга!
А теперь сравните сколько в принципе времени и слов понадобилось, чтобы, по сути, рассказать, как устроена методология счетоводной системы ТМА. В общей сложности меньше 1000 слов. Четыре основных разреза, каждый из которых имеет свой простой и уникальных набор аналитических признаков. Общая базовая структура аналитик изображена в виде пирамиды. Всего 16 вариантов движений между счетами, которые понятны любому человеку интуитивно.
В этом и заключается простота и доступность методологии ТМА, которая стала возможна благодаря использованию инновационных технологий в основе и проработке без относительно каких-либо стандартов в интересах обычных собственников малого и среднего бизнеса и его руководства.
Это я к тому, что, если кому-то сейчас показалось все это сложным, то это еще далеко не сложно! :) Сложно в классической бухгалтерии, поверьте на слово. Нам, чтобы на практике добиваться ТМА результата нужно понимание, которого гораздо проще добиться, чем получить мегатонны знаний условностей, которые нужны для работы с классическими моделями счетоводных систем.
Необходимый минимум знаний мы уже получили! Дальше двигаемся вперед к эффективной практике.
Урок. К1.М2.0007. Информационные технологии для учета.
В прошлых уроках мы определились с результатом, поняли методологические и технологические изменения для прорывной эффективности при его достижении. Надо набраться еще немного терпения и сделать последний шаг к реальной практике достижения этого результата.
Надо понять, как работают информационные технологии!
Это не просто важно, а "must be".
Во времена бумажного учета каждый бухгалтер (специалист, который занимался учетом) великолепно знал, как устроена система счетоводства изнутри. Это как раньше любой водитель знал, как устроен автомобиль и мог его ремонтировать. Но сейчас бухгалтер – это человек, который научился пользоваться программой 1С Бухгалтерия и знает определенную часть законодательства. Типа, чтобы водить автомобиль не надо знать его устройство. Достаточно изучить правила и научиться ездить.
В аналогии ситуация понятна? 😊
А вот с учетом, думаю это неправильная аналогия. В основе современного учета лежать информационные технологии. Их незнание приводит к учету на Excel. И это просто беда.
В этом уроке я объясню очень простые и базовые вещи в информационных технологиях, которые откроют Вам глаза на многое.
Айтишники, как и бухгалтеры прячут простоту за кучей умных слов и аббревиатур. Мы будем говорить очень простыми словами, и, надеюсь, сложные вещи для Вас станут простыми. Это все нам нужно для достижения результата в обязательном порядке.
Учет – это работа с данными. Мы должны собрать данные, их где-то сложить в упорядоченном виде, а при необходимости использовать их для составления отчетов.
Используя современные технологии данные всегда хранятся в базах данных, которые на схемах обычно изображаются в виде цилиндра.
Что такое база данных?
Уж точно не файлы типа Excel!
Как и в управленческом учете с определениями тут не меньше проблем.
Вчитываться в скрин из википедии не обязательно!
Попробуем понять, что такое данные в этой базе.
Единица данных – это строчка в таблице.
Столбики (поля) этой таблицы определяют признаки данных.
Для любителей и знатоков Excel – это форма списка. Только в базе данных это устойчивое состояние таблицы, а в Excel это вариант оформления.
От сюда следует, что база данных – это база этих строчек. Только в базе данных может быть множество видов данных, поэтому таких разных табличек тоже множество.
Давайте возьмем очень простой пример.
Есть данные о расходе денег. Каждый расход – это отдельная строчка в таблице «Расход денег». Каждая строчка имеет устойчивый набор признаков (полей): дата, сумма, контрагент и т.д.
Строчку на скрине открыл в виде формы. Обычно так удобно визуализировать единицу данных из базы. И для примера открыли другой вид данных – таблицу «Контрагенты». Для заполнения признака данных в таблице «Расход денег» поля Контрагенты используется данные из таблицы «Контрагенты». Т.е. в базе данных есть связи между таблицами.
Я думаю, подавляющее большинство учащихся сталкивались не только с Excel в учете, но и другими программами, где есть формы, которые заполняются из множества справочников.
Неважно сколько таблиц, неважно сколько полей в каждой таблице, не важно сколько связей. Виды полей и связей тоже неважны. Важно понять, что база данных состоит из множества таблиц, где строка – это единица данных, а поля таблицы определяют признаки этих данных, и то, что таблицы могут быть связаны. Пока все!
Это вся сложность устройства базы данных. Не нужно залезать глубже и пытаться понять, что действительно подразумевают под понятием реляционной базы данных. Нам для того, чтобы понять, как устроен и работает современный учет достаточно этих небольших и очень простых знаний.
Для пользователя база данных – это программное обеспечение, которое снабжено кучей функционала для работы с данными. Такое программное обеспечение называют СУБД (система управления базами данных). Популярные СУБД: MySQL; MS SQL; Oracle; Postgres и т. д. Среди них есть платные и очень дорогие и есть бесплатные. Платность в данной ситуации не определяет качество и функциональность. Например, Postgres самая бесплатная и одновременно самая мощная СУБД. В инструментарии ТМА в настоящее время мы используем MySQL, как основную СУБД, хотя TMAPlatform, на которой реализованы инструменты ТМА, позволяет работать с любыми СУБД.
Для людей, кто хорошо знаком с 1С. Есть обычная версия 1С, там СУБД встроенная и разработанная самим 1С, а есть серверная 1С, там можно использовать для хранения данных несколько разных СУБД на выбор.
Физически данные хранятся на жестком диске в виде одного или набора файлов, с которыми работает СУБД. Пользователь напрямую не взаимодействует с базой данных, поскольку общаться с ней надо на языке запросов SQL, а мы его не знаем и знать не желаем (возможно и не помешало бы, но я так и не собрался освоить этот довольно простой язык).
Этим языком владеют программисты и аналитики, работающие с различными базами данных. Аналитики обычно общаются с базами данных напрямую. Просто спрашивают: «Дай мне данные из такой-то таблицы такое-то поле значение, отфильрованное по такому-то полю». Мы можем не знать самого языка, но сам запрос можно выразить и обычным языком и вот это полезный навык. Просто понимая структуру, как сложены данные в базу, можно для программиста ставить правильные задачи. Например, понадобилось вам в программе учета в 10 000 документов исправить статью ДДС. Что для этого надо? Открыть каждый документ, исправить поле статьи ДДС и нажать кнопку ОК. На один документ уйдет секунд 10. Если работать в режиме робота, то на всю работу может уйти чуть больше 27 часов. Вместо этого вы подходите к человеку, который имеет административный доступ к базе данных и умеет формулировать запросы на SQL. Просите изменить поле статья ДДС в определенной таблице, в записях с определенными условиями. Тот открывает какое-то окошко и там пишет: “Update …”. Через несколько секунд Вы получили желаемый результат. Сравните, 27 часов или несколько секунд!
Другой пример. Наши программы позволяют получать какие-то отчеты, которые далеко не всегда соответствуют нашим требованиям. Понимая структуру базы данных и то, как можно у этой базы запрашивать информацию, от нее можно получить все, что угодно, в любом необходимом виде. Обычно этим занимаются аналитики. Они работают, как переводчики. Кто-то общими словами рассказывает, в каком виде и какую информацию он хотел бы видеть. Аналитик знает или может посмотреть структуру баз данных, из которых можно сформировать эту информацию, и умеет общаться с базами данных на языке запросов. Он прописывает запросы, получает и формализует данные в нужную информацию. Но в этой связке есть слабое место. Во-первых, далеко не все из вас вообще знают, что такие аналитики существуют, во-вторых, не понимая базовых вещей работы с данными, Вы сами можете недостаточно корректно формулировать требование, или вообще его не сформулировать.
Самый самый выдающийся пример, как раз в бухгалтерии. Когда бухгалтерию переводили на компьютере, то разработчикам объяснили, как система работает на бумаге и в соотвествии с правилами и стандартами. Вот они именно так и сделали. В действительности ученые (если бухгалтерия - это наука) должны были переосознать структуру системы счетоводства с парадигме новых информационных технологий и соотвественно создать новую компьютерную бухгалтерию. У них бы получилось что-то наподобие ТМА.
Как только Вы скинете оковы незнания элементарных основ работы с базами данных, так для Вас сразу откроется истинная свобода современных информационных технологий. Для меня это произошло много лет назад, но ощущение того кайфа забыть невозможно.
В общем случае пользователь имеет дело с каким-то пользовательским программным приложением, в котором есть сотни и тысячи различных уже проработанных функций работы с данными. Например, Вы отрываете программу 1С Бухгалтерия. В ней открываете в меню документ «Поступление товаров и услуг», и на экране видите список этих документов. В момент, когда в меню программы был выбран пункт, открылась форма списка этих документов, программа 1С бухгалтерия обратилась к базе данных с запросом: «Дай мне список документов из такой-то таблицы». База данных выдала эти данные и программа 1С заполнила удобную для пользователя форму списка в окошке на мониторе.
Связь пользовательской программы и базы данных называется Клиент-серверная архитектура. Клиент – это ваше пользовательское программное приложение, а сервер – это база данных.
Для того, чтобы Вы раз и навсегда поняли, почему программа тормозит.
Данные лежать в записанном виде на жестком диске. Чтобы положить туда данные, изменить или забрать, нужно взаимодействовать с физическим жестким диском.
Компьютер умеет очень быстро считать (производить вычислительные операции с использованием процессорной мощности), но все, что касается взаимодействия с жестким диском требует времени!
Вот этот момент очень важно осознать!
Например, принципы взаимодействия с базами данных, заложенные в 1С, не оптимизированы в достаточной степени. Поэтому и только поэтому 1С считается тормозной!
А вот теперь немного про оптимизацию.
Когда мы начинаем работать с данными, то их становится очень много. 😊
Сейчас я расскажу только в очень общих чертах про оптимизацию. Этого должно быть достаточно для учета.
Часть обработки данных можно делать в самой СУБД. Таким образом их не надо забирать из базы, чтобы обрабатывать на клиенте и класть обратно в базу. А получать сразу готовыми. СУБД – это очень мощное программное обеспечение, в котором очень много очень круто сделанных функций работы с данными. 1С очень не любит использовать функции СУБД, а любит все делать сама. Вот и ответ на вопрос: «А почему она такая тормозная?».
Чем больше запросов, тем тормознее.
Представьте, что вам надо собрать отчет из данных, которые разбросаны по нескольким документам, т. е. находятся в разных таблицах базы данных. Программист может пойти двумя путями. Можно к каждой таблице написать свой запрос, получить данные и из них собрать отчет. Получится несколько запросов к базе данных.
А можно в базе данных сделать специальную таблицу, при обращении к которой она соберет данные из нескольких таблиц и отдаст их. Получится всего один запрос.
Думаю, что Вы уже догадались, какой вариант будет работать быстрее. Причем в разы. С тормозами по запросам есть экспонентная зависимость между числом запросов и тормозами. Чем больше количество запросов в арифметическое прогрессии, тем больше тормозов в геометрической прогрессии.
Такая таблица в базе данных называется view, по-русски – "представление", а мы называем просто «вьюха».
Хотите, чтобы отчет работал быстро, то надо подумать, из каких данных, из скольких таблиц он будет состоять и, при необходимости, сделать вьюху.
В 1С подобие вьюхи – это регистры.
Я думаю, что понятие OLAP тесно взаимосвязано с использованием вьюх. Вьюха в олап терминах – это многомерный куб. Я много времени потратил, чтобы разобраться в дебрях олап технологий, но так сути толком и не понял. Много, очень много умных слов про аналитику, многомерные запросы и т. д., но если понимаешь простые основы устройства баз данных, то это все начинает казаться маркетинговыми упаковками. Многомерность любой таблицы в базе данных определяет множественность признаков (множество полей) каждой записи. На множестве признаков записи одной таблицы мы можем построить любую сводную таблицу и крутить ее по принципу многомерного куба. В термине OLAP главным определением является «онлайн», т. е. данные мы получаем «на лету». Мне кажется, что это связано с оптимизацией на вьюхах, описанной выше, а значит ускорением ответа на запросы данных. И все это просто упаковано в красивые для ушей заказчиков словечки.
Следующим шагом принципиальной оптимизации является материализация вьюх.
Это функция СУБД.
На то, чтобы собрать при запросе данные из нескольких таблиц внутри базы данных вьюхе тоже требуется время, хотя и много меньше, чем собирать это внешними запросами. Для того, чтобы ускорить процедуру сбора используются методы материализации. Умное слово, но смысл простой. Если обычная вьюха – это пустая таблица, заполняемая по внутренним запросам при внешнем запросе к ней, то материализация обеспечивает ее исходную заполненность.
Она не пустая, а уже заполненная. Ее заполнение может идти различными путями. Например, при изменении любой исходной таблицы изменяется и наполнение вьюхи. В этом случае ее состояние всегда актуально и при внешнем запросе, она просто выдает данные наружу. Или при изменениях исходных таблиц могут устанавливаться метки, о произошедших изменениях. Тогда при внешнем запросе, вьюха собирает не все данные, а только те, которые изменились.
По практике материализация вьюх – это очень хорошая оптимизация. Например, в 2009 году у меня триада финансовых отчетов по одной из клиентских баз считалась 10 минут. После применения оптимизации в виде материализации представлений в ТМА, этот отчет стал считаться в доли секунды.
Еще раз повторю. Вы, как руководитель или специалист по учету можете не сталкиваться в повседневности с необходимостью понимать, как работает база данных и оптимизация, но знать Вы это должны!
Ну и наконец еще одна маркетинговая, в прямом смысле, оптимизация – это онмемори технологии (все определения даю условно). Онмемори в смысле onmemory (в памяти).
Надеюсь, все учащиеся понимают разницу между оперативной памятью и жестким диском в компьютере. Оперативная память работает очень быстро, и она очень дорогая. Жесткий диск медленный, даже с появлением SSD (твердотельный накопитель). HDD – это жесткий накопитель, информация на который записывается, как на пластинку. Если видели разобранный диск, то видели в нем маленькую пластинку, которая крутится. SSD – это твердотельный накопитель, там нет пластинки. Он работает во много раз быстрее. Программное приложение (Клиент) крутится в оперативной памяти, а база данных (Сервер) лежит на жестком диске. Все тормоза находятся на запросах, и связано это с тем, что с диска надо сосчитать информацию и забрать в оперативную память, где работает ваше приложение. Фактически тормоза – это скорость чтения жесткого диска.
Шло время, оперативная память дешевела и появилась, хоть и недешевая, но возможность держать всю базу данных прямо в оперативной памяти. Естественно, тормоза на запросах в таком варианте исключены полностью. Но есть своя проблема. При отключении питания можно потерять все данные, 😊 но решается это параллельной потоковой записью на жесткий диск, так что потери будет незначительными.
Первыми на моей памяти на рынке стали громко кричать про технологии онмемори BI система click view.
Сейчас много, кто заявляет, что у них мегакрутая система, способная сформировать за несколько секунд отчет, который раньше считался несколько суток.
В действительности это просто система, которая работает с базой данных, находящейся в оперативной памяти. А за это платить будете Вы, либо покупая дорогостоящую оперативную память в свои сервера, либо за использование, например, Azure, платя за время использования ресурса.
Однажды я был на практикуме SAP HANA. Это тогда была новокупленная лидером рынка ERP систем немецкой компанией SAP, система, созданная каким-то очередным стартапом. Мы два часа по пошаговым инструкциям ставили эту систему себе на ноутбук. Чтобы эта система работала, надо было подключиться к американскому сервису, продающему компьютерные ресурсы. Для того, чтобы это сделать, надо было вводить номер своей пластиковой карты, но для практикума эти ресурсы были предоставлены бесплатно. Два дня мы крутили на тестовой базе эту программу и нам заявили, что мы можем потом еще покрутить дома. Через неделю я еще раз зашел в систему, посмотрел 20 минут и удалил с компьютера. Каково было мое удивление через некоторое время, когда я обнаружил, что у меня с карты списали 480 долларов США. Стал разбираться, оказалось, что это за те 20 минут использования их ресурсов. Спас хороший английский и неделя переписки. Деньги мне вернули. Но для Вас это должно быть измерителем того, сколько стоит такая оптимизация. И это совсем не достоинство компьютерных программ.
Например, СУБД MySQL имеет возможность настройки, когда она будет работать практически в режиме онмемори.
Насколько я столкнулся на практике для целей финансового учета такая оптимизация уже излишняя. У меня на обычном маленьком сервере за 5 000 рублей в месяц крутится 10 компаний и ресурсов хватает.
Замечу, что все данные о нагрузочных испытаниях, типа «наша система может обработать 1 млн операций в секунду», очень условны.
И последнее, но первое! Про оптимизацию конкретно в учете. Как уже многократно сказано, не надо записывать в базу вторичные данные!
Например. Есть данные о поступлениях на склад и данные о выбытии со склада. Вам нужна информация об остатках на каждый из моментов времени. Остатки – это вторичные данные, потому что они рассчитываются из данных о поступлениях и выбытии. В базе данных должны лежать данные только о поступлениях и выбытиях. Когда Вы захотите получить остатки по складу, то программа запросит первичные данные и посчитает остатки на любой момент времени налету.
На моменте вторичных данных остановимся подробнее. Поскольку это камень преткновения. Человеку свойственно думать, что если мне надо иметь информацию об остатках на складе, то ее надо заранее посчитать и держать записанной. Это по разумению должно дать возможность быстро посмотреть ее в любой момент. Но в современных информационных технологиях это неправильно. Процессор у компьютера в действительности очень быстро считает. Тут нет ограничений. Если нужны какие-либо расчетные данные, то они будут вам предоставлены без задержек с расчетом налету. Запись же вторичных данных в базу влечет за собой большие проблемы.
Как мы уже поняли, взаимодействие с базой данных – это тормоза, которые надо максимально исключать. Но главное не в этом. Если Вы будете изменять первичные данные, то рассчитанные и записанные остатки надо пересчитывать и перезаписывать. Представьте, что было сделано миллион операций поступления и выбытия. Это значит, что миллион раз была рассчитана и записана в базу сумма остатка. И вдруг оказывается, что первую операцию поступления надо исправить. Это лишь одна цифра, но программе придется пересчитать миллион остатков (это не проблема) и снова записать их в базу, а это уже тормоза. Но самая главная проблема, что надо будет как-то следить за тем, чтобы остатки (вторичные данные) соответствовали поступлениям и выбытиям (первичным данным). Иначе, изменив первую операцию, остатки не изменятся и мы потеряем делостность базы данных.
И это все не нужно и не имеет смысла, потому что компьютер умеет очень быстро считать.
Один из главных принципов ТМА – мы не учитываем вторичных данных.
В 1С есть даже понятие «регистры накоплений». Вот настолько сильна привычка того, что расчетные данные, накопления надо заранее посчитать и записать. Но это неправильно!
Модульность и интеграция.
Еще один очень важный ИТ момент для учета.
Сподвижники единых ERP систем навешали ярлыков типа «ласкутная автоматизация» (негативно) и «бесшовная автоматизация» (позитивно).
Я утверждаю, что время больших и неповоротливых систем, обладающих, как бы, всеми необходимыми функциями, прошло.
Сегодня время интегрированных систем.
Объясню.
В большой ERP системе по определению есть все необходимые для управления функции. Поскольку это заключено в единой системе, то определено преимущество в отсутствии проблем с обменом данных между разными системами. Но по факту на практике настроить обмен данными в действительности нет никаких проблем. А вот по качеству каждой отдельной функции в большой ERP системе вопросов много. А еще больше вопросов с возможностью приведения каждой отдельной функции к достаточному качеству и уникальным требованиям. Варианты доработок, как сейчас общепринято в 1С, чреваты и по общим обновлениям системы и по возможностям. Любая функция связана с другими функциями системы определенной логикой и при доработке эту логику необходимо сохранять. Плюс каждая отдельная функция – это как дом, имеет основу (фундамент) и уже на нем построенные стены, окна, крыша. Все, что можно сделать, это косметическую переделку. Сносить несущие стены нельзя, как и возводить на фундаменте то, что в нем не предусмотрено.
Производители узкоотраслевых и узкофункциональных систем фокусируются на функции в узком сегменте. Результат для потребителя по отдельной функции однозначно лучше, чем от производителя большой универсальной для всех системы со всеми функциями. Соответственно, если делать функциональные сборки, то общий результат будет более качественный.
Сегодня автоматизация – это уже не просто инструмент, типа деревянных счет в прошлом. Автоматизация сегодня – это инструмент повышения конкурентоспособности. А мы все знаем знаменитое правило Портера: «На абсолютно конкурентном рынке суммарная прибыль всех игроков стремиться к нулю». Это значит, что каждый возможный фактор повышения конкурентоспособности имеет очень важное значение.
Любая современная система автоматизации должна уметь легко интегрироваться с другими системами.
В чем проблемы интеграции?
Дело в том, что структура базы данных системы фактически определяет логику самой системы, которую законодательно защитить практически невозможно.
Производители, которые начинали разрабатывать свои большие и мощные системы еще в 90-е и в начале нулевых стремились защитить свои ноу-хау физически. Для этого они делали закрытые базы данных, с которыми можно интегрироваться только через предоставленные этими производителями сервисы.
Если посмотреть такую базу данных, то там все таблицы и все поля в таблицах будут под обезличенными номерами. Понять, как устроена такая база невозможно, а значит и невозможно «своровать» логику системы. Дешифратор такой запутанности зашит между клиентским приложением и самой базой данных. Но при производстве сервисов для интеграции производители много что не могут учесть и возможности ограничены.
Самым вопиющим примером этого является наша самая популярная система 1С. В свое время, когда звучала аббревиатура РБД (распределенные базы данных) у одноэсников начинал нервно дергаться глаз. Сегодня уже лучше, но суть осталась прежняя.
Но практика показала бестолковость всех этих заборов и преград. Логика систем настолько сложна и взаимоувязана и настолько быстро развивается, что смысл банального копирования теряется.
Если у системы база данных открыта, то проблем интегрироваться с ней нет никаких. Соответственно при автоматизации можно выбирать узкофункциональные системы с открытыми базами данных и строить комплексную автоматизацию через настройку добротной интеграции всех этих систем.
Второй большой проблемой больших комплексных систем автоматизации является единая структура. Альтернативой является модульность.
Если у большой системы модульная архитектура, то проблем с адаптацией по функциям и доработкой под уникальные требования возникает значительно меньше.
Модульная архитектура – это когда одна программа, как бы, состоит из множества самостоятельных и связанных друг с другом программ.
1С не является модульной системой, хотя иногда ее так представляют. Каждая конфигурация 1С является отдельной программой с общей структурой. Не так давно появилась возможность создавать расширения конфигураций. Фактически 1С стала двухмодульной системой. Один модуль – это от производителя, а второй, то, что разработали сами для себя и эти два модуля связаны внутри единой системы.
Отсутствие модульной архитектуры порождает проблемы с доработкой и обновлениями. Проблемы обновлений в 1С известны всем не понаслышке.
В модульной системе есть возможность взять маленькую функцию и полностью ее переработать под себя, в том числе и с изменением фундамента, при этом обновления от производителя других модулей все будет без проблем работать.
В принципе вышесказанного должно быть достаточно, чтобы сделать и принять один простой вывод:
Для автоматизации нужно использовать узкофункциональные системы с открытыми базами данных. А если система общая и большая, то нужна модульная архитектура (возможность полностью перестраивать отдельные модули, без потери обновлений, разрабатывать и подключать новые модули).
Домашнее задание ко второму модулю.
Домашние задания выполняете в Google Docs. В доступе открыть возможность комментировать. Для передачи файлов размещаете их отдельно, а в ответы по ДЗ добавляете ссылку на файл (либо посылайте файлы в виде приложения к письму). Ссылку на сам файл с ответами по ДЗ посылаете на почту tutoring1@aCCCell.com. Когда ДЗ будет принято тьютором, он и только он вручную открывает доступ к следующему модулю.
-
Почему для управленческого учета и отчетности повсеместно используется Excel или Google таблицы? Ваша версия.
-
С какими неудовлетворенностями в учете при использовании Excel Вы сталкивались в своей практике? Что именно Вам не нравилось? Попробуйте сформулировать причины этих явлений, которорые вызывают неудовлетворенности. Например, постоянно нахожу ошибки при внесении данных по причине невнимательности людей, но думаю реальная причина, что невозможно системно контролировать правильность внесения цифр.
-
Приведите примеры, если сможете, когда бизнес нес потери по причине неверно принятого управленческого решения, по причине недостатка управленческой информации. Например, я в молодости закупил в свой автосервис подъемники, чтобы заполнить машиноместа, которые пустовали, но по факу значительно уменьшил товарные запасы по дополнительному оборудованию и на дистанции в год понес значительные убытки.
-
Что потребляет и производит счетоводная система? Какой базовая технология лежит в основе любой счетоводной системы?
-
Что мы получим, если данные из таблицы ДОЦ умножить на данные из базы учета стоимостей.
-
Сопоставьте пять разделов учета по МСФО с четыремя основными разрезами учета в ТМА.
-
Почему струтура учета не изменилась, когда стали вести учет на компьютере а не на бумаге, хотя очевидно, что это должно было произойти? Не пытайтесь ответить "правильно". Пишите, что думаете.
-
Как устроена база данных?
-
База данных состоит из двух таблиц. Платеж расходы, как в тексте и контрагенты. Сформулируйте запрос к базе данных, чтобы получить движение денег по контрагенту Иванов.
-
Мы хотим составить отчет, в котором будут данные из 10 ти разных таблиц базы данных. Каким образом оптимальнее организовать взаимодействие нашей программы с базой данных.
-
Что такое вторичные данные? Приведите три примера.
Практика К1.М2.002. Настройка отчетов и ввод операций в ручную. Контроль финансового состояния и результатов деятельности.
1. Сформируйте Excel или Google таблицу, как в уроке. Внесите туда 20 различных событий (операций), при этом контролируйте свой баланс. Пришлите полученный файл или ссылку с доступом.
2. Делай как я. Смотрите видео и делайте, как я. Потом внесите еще 10 любых операций, каждая на отдельный день. Проанализируйте полученной состояние и результаты на управленческой триаде отчетов. Жду анализ в гугл док и файл архива полученной базы.