Это классный вопрос, хоть и с долей иронии. Классный тем, что суть контроля в бизнесе — это «на остатках». Кассовый аппарат позволял видеть расчетный остаток денег в любой момент времени, а значит была возможность пересчитать наличные и сверить с расчетной суммой на кассе. Это и предотвращало воровство наличных.
С товарами ясное дело сложнее, но все верно, контроль по инвентаризации.
В целом общие остатки по бизнесу — это отчет Баланс. Я полжизни создавал систему, которая позволила бы контролировать баланс в масштабе реального времени. Не только остатки денег, но и остатки всех ценностей и остатки взаиморасчетов. Есть расчетные остатки, значит в любой момент можно проверить. И такая система позволяет большую часть воровства предотвратить. Оно может быть, но при этом будет более изощренным.
У меня бизнес в общепите. Там воровство в норме. Я могу по три месяца вообще отчеты не смотреть. А потом посмотрю полчаса и у директора и у сотрудников удивление, от куда я все знаю? Они не могу ничего списать, чтобы я это не увидел. Они могут воровать только по сложной схеме взаимодействия с поставщиками и одновременном несоблюдении калькуляций. Но для них это высший пилотаж :).
Когда мы в одно агентстве недвижимости внедрили нашу систему, кстати она называется ТМА, через полгода это агентство умерло. Прикол в том, что система не давала возможности воровать сделки. А в этом бизнесе это в норме и это большая часть дохода крутых агентов. Свое агентство платит 20% за сделку, а если ее отнести к конкуренту, то получишь и 60-80%. Вот там и носят он нашего к конкуренту, а от конкурента к нам. :). Когда перекрыли эту возможность за счет контроля остатков (в данном случае состояния ведения взаимодействия с клиентом), то все крутые агенты разбежались, ведь они не могли зарабатывать как обычно. А директор не догадалась, что эту потерю надо компенсировать и платила честный процент наравне с конкурентами.
Видимо все дело не в том. что сам кассовый аппарат решал общую проблему и всем был нужен, а в том, что Паттерсон смог продать эту идею миру, как это сделал Стив Джобс с множеством своих продуктов.
Автору спасибо! С огромным удовольствием прочитал от начала и до конца. Зацепило начало, которое было не про Паттерсона, а про изобретателя кассовых аппаратов, который сам эти аппараты не смог продавать. Потом о том, как Паттерсон выстроил гигантскую машину продаж.… Нож по сердцу. Я полжизни создавал систему, которая не позволит воровать, сначала для себя, потом 10 лет пытался продавать. Тоже есть патент на изобретение, от которого ноль толку.
Генеральному директору не выгодно, чтобы для собственника бизнес был прозрачным. А куда без ГД (приказчика) :). и где этот Паттерсон....???
Первое внедрение большого пакета 1с у себя в бизнесе я провел еще в 2003-4 годах. Тогда новоиспеченная 8. Почти год проекта. Плюс пять человек в штате. Несколько контрактных проектов по доработке, обучению и внедрению. В итоге сделал вывод, что прозрачным и более управляемым бизнес для меня не стал. Наоборот. Слишком много моего времени стало уходить на игру в 1С. Стало сложно сосредотачиваться на бизнесе и как-то все стало наоборот более тяжелым и менее управляемым. Это по ощущениям. Тогда у меня возникла аналогия 1С с компьютерной игрушкой. Закончил простой этап, иди на следующий. В принципе все тоже самое только монстры побольше размером, орудие против них покруче. Перебил этих, следующий этап, пока не приходишь к чему-то практически невыполнимому. А в целом любая компьютерная игра - это самоубийство. Потому что жизнь - это время, которое убивается во время игр.
В последующие годы 1С в моем бизнесе присутствует только по функции фискальной бухгалтерии. А вся эта история привела меня с одной стороны в бешенство, а с другой....
Я выгнал всех эсников, похерил все проекты, вернулся к исходной точки и тому софту и икселю, который был до этого. Немного подналадил это все за месяц и вздохнул свободно. Такое ощущение, что вышел из душной комнаты на свежий воздух.
Но потребности в большей управляемости и прозрачности, которые привели меня к потере нескольких десятков тысяч долларов и почти года жизни на игру в 1С, остались. Нужно было решение. 1С уже тогда была монополией и альтернатив не было.
Да, кстати, решится на откат ситуации было очень сложно. Я так понимаю, что большинство втягиваются навсегда.
Мое решение было экстраординарным. Я вошел в состав учредителей софтверной компании, которая делала софт, на котором я работал. И стал диктовать нужные мне решения. Ничего не получилось.
Потом создал свой проект и свою команду разработчиков. В результате основным моим бизнесом стала разработка ПО для автоматизации бизнеса. Хотя обычный земной малый бизнес продолжает работать и я даже создаю новые направления, но операционным управлением не занимаюсь. Все мое время посвящено направлению автоматизации бизнеса, а особенно управленческого учета.
Эта часть моей истории позволила взглянуть на 1С изнутри рынка, а не как потребитель.
В принципе кто-то может сказать, что я типа стал конкурентом 1С. Нифига подобного. нет никакой конкуренции. В России 1С для малого и среднего бизнеса - это среда обитания, как и для всех компаний, которые хотят зарабатывать на автоматизации малого и среднего бизнеса.
У нас нет рынка автоматизации, а есть рынок 1С. Это надо понять. Какой смысл критиковать состав воздуха земной атмосферы, которым мы все дышим?
Вопрос почему Нуралиевы смоги создать такую монополию и как?
Описанный в статье аргумент - это плюс к десяткам других более ранних аргументов.
В первую очередь 1С - это первые 10 лет лучшее решение по фискальному учету, который нужен на всех предприятиях. Это ядро и вход в рынок.
Это платформа! Платформа, на которой идет разработка прикладных решений и она сама эти решения исполняет. Т.е. чтобы изменить программу не надо выпускать новую версию. изменили код, перезапустили и обновления применились. Идея платформы для автоматизации бизнеса очевидна, поскольку все бизнесы разные и ситуация и бизнес-процессы постоянно меняются, то автоматизацию постоянно надо подкручивать под эти изменения. Это очевидно и правильно. Доказательства? Пожалуйста. Тройка мировых лидеров ERP - это платформы. А микромягкие, чтобы выйти на этот рынок купили аксапту, которая до этого выкупила своего конкурента навижн. и та и другая - это платформа.
1С - это партнерская сеть (франчайзи тут только в качестве названия). И вот идея этой партнерской сети была первой и самой мощной. (Это произошло, когда Нуралиев, внедряя вроде Лотус, слетал в холодную Сибирь, прилетел обратно, а ему звонок, что надо возвращаться, другой клиент его хочет. Там был местный который ему помогал. Нуралиеву возвращаться не очень хотелось. Он позвонил этому местному и предложил ему за 50% сделать этот проект на месте. Все получилось и это был прототип современного 1С партнерства). Ключевым элементом этой партнерской схемы является возможность зарабатывать! Те же постоянные недоработки конфигураций - это банально возможность зарабатывать партерам 1С (платформенность тут пришлась кстати). десятки тысяч партнеров постоянно делают одно и тоже для сотен и тысяч клиентов и получают за это прибыль. Идея "дай партнеру заработать" сработала на все 100. Хочешь зарабатывать на автоматизации? лучший способ - это стать партнером 1С и заниматься продажей лицух 1С и постоянными доработками. Тут даже про внедрение особо речи не идет. Самые красавцы в этой армии - это первый бит.
Ситуация замкнулась сама на себя. Большинство спецов, которые специализируются на автоматизации - это одноэсники, среди который реальных айтишников, программистов, руководителей проектов автоматизации, однозначно меньшинство. Большинство - это люди которые вошли в айтишку и автоматизацию исключительно со стороны 1С. Они не могут сравнивать, потому что они больше ничего не знают. И вот что получается. Потребитель - предприниматель, директор, финдир, бух или еще кто-то, кто понимает что ему надо автоматизировать ищет специалиста, который бы ему объяснил, что лучше выбрать. Ведь это сложно функциональный вопрос, и просто погуглить не получится. Он обращается к сообществу специалистов и в подавляющем большинстве случаев попадает на человека, который ЗАРАБАТЫВАЕТ на партнерстве 1С. Что он посоветует??? То, на чем он зарабатывает! Т.е. он приведет тысячу и один довод, что 1С идеальное решение. Даже если заказчик попробует поискать альтернативы. Да пофигу, он же полюбому опять попадет на эсника. :). Если среди этих специалистов попадется не эсный айтишник, если он даже будет круто и очень круто во всем разбираться и приведет миллион доводов, а десять других будут говорить в пользу эски, то подавляющее большинство заказчиков обратятся к эске.
Тут вспоминается фильм Револьвер "Чем больше человек вовлечено в разводку, тем ее проще провернуть. Ведь не может быть, чтобы так много людей повелось ..."
В завершения этого постообразного комментария хочу сделать вывод. Время идет и ситуация меняется. сейчас уже нет разработок с нуля и альтернативные предложения становятся реально заметными. Думаю совсем скоро, какой-то механизм спускового крючка сработает и вся эсная модель развалится.
Кстати по CRM Нуралиевы целенаправленно скупали стартапы, сначала битрикс, потом мегаплан ну и так далее до амо. И если это происходило на ваших глазах, то вы знаете как здоровое решение тут же заражалось вышеописанной бизнес моделью 1С. Партнеры, доработки и т.д.
Класс! Кайфанул и прочитал от начала до конца. Моя компания очень похожа на вашу, только мы разрабатываем ПО под управленческий учет. С 2009 года ведем поминутный учет. Для этого сами разработали софт, назвали его СУВР (система управления временными ресурсами). Кстати готов с вами поделиться им. Мы его не продаем, это чисто для себя.
Есть одно замечание. Проекты можно считать без накладных — это валовая прибыль. Кстати мы прибыльность по проекту контролируем риалтайм, поскольку таймшиты закрываются ежедневно и начисления приосходят ежедневно. Прямые типа командировочных тут же в проектах учитываются. А вот накладные типа офиса — это постоянные расходы. их к расчету стоимости времени лучше не прилеплять. Тут простая система управления через точку безубыточности. когда на графике переменные затраты пересекаются с постоянными. Спасибо за материал. И мы тоже из Питера.
За труды конечно плюс! Попробую немного подсказать направление.
Учет только движений денег не дает хорошего управленческого эффекта. Учитывать необходимо все варинаты операций. Как говорят доходы расходы «по начислению», но лучше так не говорить.
Цель — финансовое состояние (богатство). Если я контролирую сумму своего финансового состояния, то я контролирую свои финансовые цели. Финансовое состояние — это остатки денег, ценностей и взаиморасчетов на конкретный момент времени.
Зачастую достаточно вручную собирать. Всегда можно прикинуть какая ценность сколько стоит и по долгам вести записи, чтобы были остатки. Деньги — это самое простое. Раз в месяц свести этот баланс и узнать цифру финансового состояния уже великое дело. Подсознание начнет работать по-другому. Человек всегда знает где сэкономить и где подзаработать. Нужен только мотив. Если в очередной раз фин состояние будте меньше предыдущего, то это великолепный пендель для подсознания.
Анализ доходов и расходов уже кропотливое и сложное дело, чем вы великолепно занимаетесь. У меня в жизни было куча попыток, но так и не смог.
Чтобы вести такой анализ нужно учитывать все операции а не только денежные. Операция — это изменение состава финансового состояния. деньги+ценности+взаиморасчеты=финансовое положение. Каждая операция это движени из одной переменной этого уравления в другую. Всего элементов 4, поэтому таких движений может быть 16 типов. Типа если дал деньги в займы. то это Плюс деньги минус взаиморасчеты. Аналитика по каждой переменной своеобразная. Деньги — это валюта, места учета денег и статья ддс. Взаиморасчеты — это контрагент, договор и статус в котором этот контрагент взаимодействует с вами (кредитор, покупатель, поставщик и тд). Ну а у финсостояния как раз и будут доходы расходы так сказать по начислению. Например, потеряли деньги, плюс Убыток (вычит из финсостояния) минус деньги.
Сложности возникнут при приведении всех этих движений в единой денежное выражение. Но если нет валют, то не очень сложно.
Таким образом возникнет ситуация, когда учтенные операции будут проверяемы. ведь финсостояние прошое плюс все операции = финсостояние текущее, которое можно проверить вживую.
Описанная систематика называется ТМА. Разработана давно, а на компьютерную реализацию даже патент получен на изобретение. Есть готовые программные модули. Если интересно, то для людей которые умеют вот так все скурпулезно вести в учете мы предоставим все программные модули бесплатно.
Перечисление симптомов. Было бы круто построить причинно-следственные связи и найти ключевую проблему, решив которую общие проблемы отваливаются пачками.
На вопрос: «Сколько тебе надо времени на решение этой задачи?», ответ программиста: «От 20 минут до двух недель» — это вполне нормально.
Ненормально, когда программист, а если он хороший, то у него мозги многопоточные, сидит и тупит над одной задачей.
В этом кстати проблема скрама. На короткой иттерации мало задач, а часто одна, приходится сидеть и тупить, вместо того, чтобы заняться тем, что идет.
Бывает так. Программист сидит тупит, сроки, обещания, все сорвано, а решения нет. Занялся другой задачей, отвлекся, и вдуг пришло озарение, вернулся на эту задачу и за 20 минут все закрыл.
Я — РП, никогда не программировал, но программистов строить обычными методами типа жесткие сроки, особенно, если разработка сложная, это крайне неэффективно.
Мне нравится тема в ТОС (теория ограничений) по управлению проектами. Там важно построить Критическую цепь проекта и контроль и управление сводится к критическим нескольким точкам, а не срокам по каждой задаче.
Огромная работа. Поставил за нее плюсы, но во многом не согласен.
Тема важная, поскольку считаю, что за интегрированными системами будущее. Времена больших ERP, где автоматизируются все функции в одной системе проходят. А если выбираешь лучшее решение отдельно для каждой функции, то интеграция должна быть действительно хорошо работающей.
Но не согласен я с подходом основанным на лечении симптомов.
Будет эффективнее находить ключевые проблемы, базовые причины проблем, которые на поверхности повседневной практики.
Например. Контрагенты, договоры, валюти и пр. — это просто таблицы в базе данных, хранящие набор признаков, которые используются в других таблицах, типа «проводки». Кстити Учетные счета — это тоже просто таблица. Если в двух системах есть таблица с функцией хранения реестра Контрагентов, то при консолидации будут проблемы. Но такие же проблемы будут с любыми другими справочными таблицами в базе данных.
Решение будет также одно. Например, мы предпочитаем урегулировать все несоответствия через таблицу «Правила соответствия» где просто указываются синонимы из разных баз и эта таблица учитывается при взаимодействии данных по алгоритмам. Но часто встречаю попытки сделать в холдингах единые справочники (по мне дак очень плохая идея).
Но больше всего в вопросах интеграции меня беспокоят закрытые базы данных. Разработчики считают что в структуре их баз прям вот ценность и делают так, что интегрироваться можно через их, зачастую очень кривое, API, без нормальной документации и с очень урезанными возможностями. Если базы открытые и могут запросами общаться друг с другом, то меньше проблем.
Когда Вы пишите вот прямо по конкретностям, но это становится учебником, который никто не читает. Для меня вопрос мега актуальный, но признаюсь честно, с третьего абзаца уже пошла диагональ.
Хочу сказать спасибо автору за статью. К сожалению срок голосования прошел. Все правильно стандартная Гауссиана для оценки вероятности в прогнозировании проектов не подходит и это обосновывает то, что при прогнозировании люди интуитивно закладывают значительно больше подстраховки, чем надо. При декомпозиции на каждый отдельный элемент закладывается своя подстраховка. В результате суммарная подстраховка очень большая. При этом проекты чаще заканчиваются не в срок, чем в срок. Вопрос очень актуальный. Почитайте книгу «Критическая цепь» И.Голдратта. Там он раскрывает все нюансы и причинно следственные связи значительно глубже, и в принципе даются практические рецепты. Однако при большой степени неопределенности любые прогнозы не будут работать. Тут вопрос гибкости. Скрам отчасти их решает, но только отчасти и в ущерб эффективности. Очень большая тема. Еще раз автору спасибо!
Почти 10 лет управляю разработкой. Сам не программист. У меня работа идет только по задачам, а учет времени даже не почасовой, а поминутный. Мы зачастую себя называем экстримальными Agile разработчиками.
Agile — изначально это возможность заказчика в ходе разработки менять требования, т.е. гибкая разработка. Модели процессов, которые придумывают люди, чтобы обеспечить такой режим разработки нельзя применять «как есть» с закрытыми глазами на текущую в конкретной команде реальность.
Получается, что в описанном результате не виноват ни сам эйджайл, ни скрам.
Если мой разработчик обнаруживает, что есть незапланированная задача, которую следует по его мнению выполнить, то он просто вносит ее. В зависимости от настройки проекта он, либо ждет согласования, либо выполняет сразу и учитывает по ней затраченное время.
На вопрос сколько нужно времени на выполнение задачи, ответ от программиста от 20 минут до 2 недель вполне приемлем! У программистов многопоточное мышление. Если он не знает, как сейчас решать задачу лучше и переключается на другую, то это не значит, что во втором потоке не идет поиски решений по первой. Надо уметь давать вызревать задаче, тогда на ее решение может уйти всего минуты. Это уже практика.
По факту хреновый был у вас менеджмент, видимо хорошего опыта разработки не имел.
Опасайтесь моделей! Модели бизнес процессов, взятые из опыта других — это лишь примеры для ваших размышлений. Принять к сведению и сделать по своему. Приблизительно такая же ситуация произошла, когда один из «наших» купил Mandriva, ввел туда менеджмент и все разработчики разбежались, а разработка была приостановлена.
Менеджмент и разработчики и много других участников процесса разработки — это части одного целого. Нельзя противопоставлять их друг другу. Причем со стороны разработчиков также нужно относится с пониманием, или хотя бы с желанием понять задачи тех, кто управляет разработкой или выполняет другие функции, в купе дающие готовый и рабочий продукт.
Много раз встречал и быстро прощался с разработчиками, которые ставили себя выше других и с пренебрежением относились к другим участникам не столь одаренным, но выполняющим свое дело. Только во взаимопонимании рождаются действительно хорошие продукты, и устанавливается комфортная среда для ведения процессов разработки. А методы должны соответствовать конкретной команде, задаче и другим условиям окружающей среды.
Всех благ.
А Вы — молодец!
И это без иронии. Все правильно.
Однако бизнес должен приносить доход, это прокрустово ложе для всех остальных целей собственника или инвестора. Если собственник забудет следить за этим бизнесу непоздоровится даже с великолепной командой и внутренней культурой. Поверьте :). это история про меня 15 лет назад. Целый новый рынок построил. 100 человек команда были как одно целое. Я тратил на это все свое время и это была моя жизнь, самореализация и все что угодно подпадающее под нефинансовые цели собственника. Но потом был конец этой сказки и подавляющее большинство команды оказались людьми способными быть нормальными только когда все цветет и пахнет. Такова природа людей и не виню их в этом. Вот следить за тем, чтобы все цвело и пахло надо было самому и это все моя ошибка. Может поэтому много лет занимаюсь этими вопросами с такой серьезностью. Так сказать палец в розетке побывал. Плавали, знаем.
Понимаете. Не могу спорить с тем, что Вы пишете. Это истинная правда и про это нужно думать и говорить. Но если Вы собственник, все же не забывайте про основную работу, следить за доходностью! И это не распределение бюджетов, это экономика, т.е. экономический прирост бизнеса должен быть всегда!
Про это и речь была в статье, а не за доход непосредственно собственника, пассивный и растрачиваемый на замки и массажистов жены.
Спасибо Вам за внимание к этой теме.
Если хотите обсуждать идеи, то не стесняйтесь пишите на электронку или в личку, Правда я тут теперь редко бываю.
«На мой взгляд, ошибка большинства «инвесторов» — это надежда на «пассивный доход».»
Я бы сказал в этом цель. Иначе зачем делать бизнес. А вот забывать не надо. О том и речь в статье. Как сохранить пассивность дохода и не терять контроль.
По поводу репрессивного аппарата не соглашусь совсем. Все зависит от бизнеса. Существуют различные методы мотивации и в разных случаях одни вредят другие помогают. Панацеи, заставляющей людей работать не думая о личном времени с полной отдачей не существует. Это как практик говорю. Со временем пришлось научиться понимать как и с кем нужно обращаться, чтобы мотивировать. Хотя подавляющее большинство любит плетку :), в этом ваша правда.
По поводу «выделил бюджет». Это один из примеров «других методов», которые я приводил в этой статье.
Спасибо за комментарий. Не думал, что эту статью еще кто-то читает. В знак благодарности еще раз обращу ваше внимание на то, что в статье пропагандируется взгляд на бизнес «сверху вниз», от общей картины к деталям, и немного раскрывается методика. Но это слишком мало, чтобы раскрыть всю проблематику.
Очень интересно!
Проблема, как сделать доступным в МСБ то, что в крупном ключевые вендоры дают за большие деньги крайне актуальный. И эти вендоры надо сказать очень этот вопрос думают, правда не лучшим образом получается.
Мы тоже создали свою платформу и системы для анализа, только решаем вопрос не моделирования, а фактического учета и отчетности. И ровным счетом также замещаем эксель в этих вопросах в сегменте МСБ и пытаемся сделать все это доступным.
Вопрос доступности заключается не только в технологической, но и в методологической составляющей, причем обе части тесно взаимосвязаны.
Получается, что Вам надо не просто дать инструмент вместо экслея, но вложить в него понятную простым малым предприятиям методологию анализа, планирования и моделирования.
Насколько я понял, Вы как раз специализируетесь на этом, поэтому такое будет для Вас возможно.
Приведу пример.
В одной консалтинговой компании клиент заказал автоматизировать финансовую модель по проектам строительства многоквартирного дома. Они четыре месяца ваяли на икселе и свояли два файла по 30 мб. Монстры. Смогли даже сдать работу и получить немаленькие деньги, но при этом хватило ума понять, что так делать нельзя. Стали искать разработчиков, кто бы этоу финансовую модель сделал бы в нормальной архитектуре, понимая, что это будет типовое решение, которое потом можно продавать подобным застройщикам.
В этом решении будет две составляющих. Одна — это непосредственно разработанная консалтерами модель, а другая — это сама программа.
Вот используя этот пример пытаюсь объяснить, что надо спускать в доступном виде в МСБ.
Мы делаем доступные методы счетоводства, тоже потратили годы и вроде бы начинает получаться.
Есть желание, давайте делиться друг с другом опытом в достижении цели дать доступные, но полноценные инструменты для МСБ в учете, анализе и моделировании, замещая иксель, который до определенного момента замечательный инструмент, но когда упираешься в потолок, то проблемы утраиваются.
Очень хочу ответить на этот вопрос, хотя и с большим опозданием.
Мы хорошо знакомы с автором этой статьи, но на поставленный вопрос отвечу однозначть ДА! Стоит. И тут смысл не в том, как пишуться цифирки и по каким счетам и в каких формах. Теперь это вообще дело иное. Езерский разрабатывал систему учета с использованием качественно иного носителя информации (бумага), чем тот, что используется сейчас.
Стоит возраждать саму идею Езерского.
По этому поводу стоит процетировать Соколова:
«Русская форма была создана в 1869 году в Дрездене. Ее создатель — русский бухгалтер-самородок Федор Венедиктович Езерский (1836-1915) — думал, прежде всего, не о том, как лучше расположить регистры и как проще работать счетоводу-бухгалтеру.
Он пытался решить главную задачу управления: отслеживать в реальном масштабе времени успешность работы предприятия. Дело в том, что все предприниматели во всем мире до сих пор, как это ни парадоксально, работают „вслепую“, то есть финансовый результат может быть установлен только после составления баланса.»
Подробнее: buh.ru/articles/documents/13508/
Официальная бухгалтерия, налоговый учет, МСФО работают в требованиях установленых правил. Так им надо. Но кроме всего этого есть собственники и управленцы, которые в гораздо большей степени заинтересованы в учете. В том, чтобы он был понятным, прозрачным и давал понятную общую картину успешности (состояние и результаты деятельности) и желательно в масштабе реального времени. Сейчас это принято называть Управленческий учет.
Вот именно в этом направлении стоит присмотреться к идеям и целям, а так же всем действиям этого великого русского бухгалтера. Мало кто в мире среди профессиональных бухгалтеров настолько хорошо понимал потребности самого бизнеса в учете и предпринимал бы такие масштабные действия по практической реализации своих разработок. Все это делается лишь с одной целью, позволить бизнесу быть лучше. Для этого учет и должен существовать и развиваться, а установленные правила регламентного учета, не важно русского, европейского или американского формата, пусть остаются правилами, нельзя на них слепо ориентироваться в бизнесе.
У меня есть мнение, что в России есть определенный смысл возрождать дело Езерского, ведь прозрачность бизнеса, которую дает хороший учет, который строится на хороших системах и ведется хорошими образованным специалистами, дает бизнесу возможность нормального взаимодействия со своими инвесторами, поставщиками, клиентами, сотрудниками и прочими в действительности внешними сторонами. Так же хороший учет дает возможность качественных обоснованных управленческих решений, а так же их тестирование на общем результате.
Чтобы получить хороший учет, нужно создвать системы (на подобе той, что создал Езерский, только в свое время), заниматься образованием собственников, управленцев и учетных работников (как это делал Езерский, только в свое время), обеспечивать информационным потоком эту отрасль, чтобы было всем понятно, о чем идет речь (как это делал Езерский, издавая множетсво относительно простых книг и журналов), и наконец поменьше смотреть в сторону «за бугор» (как это дела Езерский), поскольку большинство приемов тамошних может просто не подходить для наших реалий.
Вот именно поэтому стоит возраждать дело Езерского и возможно его имя использовать как знамя для возраждения направления русской, понятной и эффективной бухгалтерии в сфере управленческого учета.
Перечитывал свои старые статьи и комментарии к ним спустя три года. Не могу признать, что должен извиниться за свои ответы на ваши комментарии. Я был не прав. У вас была четкая и обоснованная терминологическая позиция. Я видимо не потрудился ее понять до конца. Хотя, конечно это у нас взаимно было :). Мне очень стыдно.
Хочу исправиться, объяснить и обосновать свою позицию.
1. Я действительно отождествляю финансовый и бухгалтерский учет. Определений этих терминов в учебиках и в интернете много. Общепризнанный факт, что единого смысла этих определений нет, очень много разночтений. Именно поэтому я обращался к основам происхождения этих терминов. Финансовые учет нацелен на создание фин отчетов, тут мы согласны друг с другом. Финансовым называется, поскольку основан на выражении данных в измерении той или иной денежной (финансовой) единицы. При чем формы имеют устойчивый вид (баланс ОДР ОДДС). Что касется бухгалтерского учета, то БУХ — это книга, или по нашему счет учета. Если дословно, то бухгалтерский учет — это ведение книг (счетов) учета. Система ведения счетов учета (счетоводство, или форма счетоводства) направлена на единственную цель, сфомировать финансовые (бухгалтерские) отчеты. От сюда мы получили полное идинообразие целей а соответственно понимание, что финансовая система и бухгалтерская система это синонимы по смыслу. У той и другой на входе первичка, а на выходе фин отчеты. А вот сужать фунцию бух учета до сбора первички по моему мнению не является корректным, видимо это дань определениям из учебников. Именно наука бухгалтерского учета породила больше ста лет назад понятие балансоведение, а баланс — это главный из финансовых отчетов. Но общее мнение современного обывателя отождествляет бухгалтерский учет с процедурами согласно установленному законодательству, причем в интересах государства. Хотя самые великие умы бух науки современности, примеру, Соколов (младший) до сих пор полагает, что бух учет — это для собственника. Чтобы отделить этих мух от котлет я и постарался заключить понятие бух учета в процедуры связанные со стандартами, и конечно не только в нашей стране. Налоговый учет — это тоже самое, только немного правила проведения по счетам отличаются. В основе и финансового и бухгалтерского и налогового учета лежит родовое понятие счетоводство. К сожалению оно подзабыто. Надеюсь теперь я свою позицию объяснил.
2. Управленческий учет. Если с прошлыми понятиями еще как-то можно разбираться, то с этим вообще не реально. Маломальский стандарт существует только в америке. В нашей стране за это понятие идет война между кафедрой бух учета и кафедрой финансового менеджмента. Они там бадаются по поводу того, кто должен учеть всему тому, что к этому понятию относится. И учат совсем поразному. Хотя, между нами, надо просто принять факт, что управленческий учет — это все то, что надо управленцу для принятия решенй. Что я в статье и утверждаю. У меня очень большой опыт управления. Обобщить и унифицировать требования к упр учету по отношеию к фин учету был непросто, но то, что вы видите это голая практика. Согласитесь, что в таких системах координат хотябы можно дальше мыслить безотносительно всего того, что понаписано различными авторами в различных учебниках. Задача стояла представить ключевую суть, а не создать очередное определение. Большинство любей живет по определениям, тут сложно спорить. Это большинство правильность определяет через сравнение с известным шаблоном, на котором написано «правильно» (Д.Э.Н. Иванов И.И.). Я по природе своей отталкиваюсь от сути. ИТ сообщество отличается тем, что большинство из них, все же, так же отталкивается от сути и способно строить довольно длинные цепочки причинно следственных связей (я имею ввиду программистов). Поэтому в статье идет выстраивание базовой сути, простой и взаимосвязанно обоснованной. Причем идет оговорка, что установка этой базы не претендует на формирвоание определний, а нужна лишь для правильного понимания дальнейшей информации, где в описании будут использоваться эти термины.
Но за последние три года на рынке возникли интересные тенденции. Управленческим учетом стали называть системы, где формируется управленческий план счетов и ведется двойная запись, а результатом являются финансовые отчеты по упрвленческому плану счетов и внутрикорпоративным стандартам (первый бит управленческий учет или Финград). Финград кстати использует довольно продвинутые алгоритмы электронного счетоводства.
3. МСФО и ГААП — это такие же бухгалтерии, как и РСБУ (я дипломированный бухгалтер по МСФО). Кстати за последние 10-14 лет рсбу очень сильно сблизилось с мсфо. Бухгалтерии в вышесказанных понятиях. Но надо отдать должное, что эти стандарты ближе к интересам собственников и не заключают в себе исключительно интересы государства. Все эти заявления категоричны и являюстя крайностями. Я встречал на практике варианты бизнеса, когда бух учета было вполне достаточно, чтобы удовлетворить упр цели, и обратную картину тоже встречал. Что дает возможность утверждать, что в том виде, в котором ведется бух учет сейчас, для целей управлеия не пригодный. Т.е. есть варианты, что его никак не приспособить, но есть и варианты, когда возможно.
4. Что касается отчета о капитале, то этот отчет является требованием стандартов. В рамках предлагаемых мной методик он не имеет такого выделенного смысла. В пассиве баланса я предлагаю вести раздел собственный капитал, где формируется статья вложенный капитал (с начала времен), изъятый капитал (с начала времен), накопленная прибыль (с начала времен), накопленный курсовые и стоимостные дельты. Сумма этих статей дает сумму собственного капитала. Это лишь подход, который предлагает Цыганков, а мне очень нравится, как собственнику бизнеса. Но это лишь подход. Можно лего формироать отчет о распределении прибыли если таковая есть или по капиталу, плюс систему финансовых показателей. Все это вторично.
Ладно, много написал. Основные разногласия, что для вас бух — это первичка, а для меня счетоводство, у которого эта первичка есть вход. На базе того, что великолепно знаю историю бух учета в деталях, думаю мое утверждение будет более корректно, особенно если рассуждать про алгоритмы автоматизации процессов построенния фин отчетов.
Еще раз прошу прощения за грубость в прошлых комментариях. Я вижу, что Вы специалист и хорошо разбираетесь в теме, просто тема эта неоднозначная.
Очень хочется вставить комментарий, что состояние (финансовое), т.е. персональное богатство, не имеет ничего общего с тратами и получением денег и доходами расходами, т.е.операциями, которые изменяют это состояние.
Учитывать траты, доходи и расходы сложно, это точно. А вот состояние учитывать нет проблем, даже программ не надо. Ссылка на статью
Где тут клавиша, чтобы плюс жирным выделить.
Только маленькая корректировка. Сами программисты зачастую далеки от специальной области, где должна проводиться автоматизация. Сами они такого понаворотят….это уже проходили. Но то, что подобные концепции должны делаться с полным пониманием всех основ программирования, баз данных и с хорошим опытом управления разработками, согласен на все 100.
Для разработки мостик взаимопонимания должен быть построен между программистом и специалистом в требуемой области, а это ооооочень сложный вопрос.
Управленческий учет, считается внутренней кухней предприятия, ведется везде, и он не официальный. Поэтому подобной потребностью нельзя обосновывать потребность к продуктам на базе ваших идей.
Это не наивно, а очень правильно. Смею заметить, что системы управленческого учета уже давно наплевали на двойную запись, именно потому что есть недостатки и ограничения, но это не значит, что в управленческом учете правильнее двойной записи. Современный упр учет – это шаг назад в технологии учета, а не вперед, просто компромисс. Для управленцев нужны такие данные и двойная запись с этим не справляется, убрали… Внешним сторонам нужна общая картина, а для этого не обойтись без двойной записи. Компромисс в том, что существует две параллельные системы учета, а это все усложняет. Должна быть одна система и разные формы информации.
С товарами ясное дело сложнее, но все верно, контроль по инвентаризации.
В целом общие остатки по бизнесу — это отчет Баланс. Я полжизни создавал систему, которая позволила бы контролировать баланс в масштабе реального времени. Не только остатки денег, но и остатки всех ценностей и остатки взаиморасчетов. Есть расчетные остатки, значит в любой момент можно проверить. И такая система позволяет большую часть воровства предотвратить. Оно может быть, но при этом будет более изощренным.
У меня бизнес в общепите. Там воровство в норме. Я могу по три месяца вообще отчеты не смотреть. А потом посмотрю полчаса и у директора и у сотрудников удивление, от куда я все знаю? Они не могу ничего списать, чтобы я это не увидел. Они могут воровать только по сложной схеме взаимодействия с поставщиками и одновременном несоблюдении калькуляций. Но для них это высший пилотаж :).
Когда мы в одно агентстве недвижимости внедрили нашу систему, кстати она называется ТМА, через полгода это агентство умерло. Прикол в том, что система не давала возможности воровать сделки. А в этом бизнесе это в норме и это большая часть дохода крутых агентов. Свое агентство платит 20% за сделку, а если ее отнести к конкуренту, то получишь и 60-80%. Вот там и носят он нашего к конкуренту, а от конкурента к нам. :). Когда перекрыли эту возможность за счет контроля остатков (в данном случае состояния ведения взаимодействия с клиентом), то все крутые агенты разбежались, ведь они не могли зарабатывать как обычно. А директор не догадалась, что эту потерю надо компенсировать и платила честный процент наравне с конкурентами.
Видимо все дело не в том. что сам кассовый аппарат решал общую проблему и всем был нужен, а в том, что Паттерсон смог продать эту идею миру, как это сделал Стив Джобс с множеством своих продуктов.
Генеральному директору не выгодно, чтобы для собственника бизнес был прозрачным. А куда без ГД (приказчика) :). и где этот Паттерсон....???
Позволю себе немного добавить перца в это блюдо.
Первое внедрение большого пакета 1с у себя в бизнесе я провел еще в 2003-4 годах. Тогда новоиспеченная 8. Почти год проекта. Плюс пять человек в штате. Несколько контрактных проектов по доработке, обучению и внедрению. В итоге сделал вывод, что прозрачным и более управляемым бизнес для меня не стал. Наоборот. Слишком много моего времени стало уходить на игру в 1С. Стало сложно сосредотачиваться на бизнесе и как-то все стало наоборот более тяжелым и менее управляемым. Это по ощущениям. Тогда у меня возникла аналогия 1С с компьютерной игрушкой. Закончил простой этап, иди на следующий. В принципе все тоже самое только монстры побольше размером, орудие против них покруче. Перебил этих, следующий этап, пока не приходишь к чему-то практически невыполнимому. А в целом любая компьютерная игра - это самоубийство. Потому что жизнь - это время, которое убивается во время игр.
В последующие годы 1С в моем бизнесе присутствует только по функции фискальной бухгалтерии. А вся эта история привела меня с одной стороны в бешенство, а с другой....
Я выгнал всех эсников, похерил все проекты, вернулся к исходной точки и тому софту и икселю, который был до этого. Немного подналадил это все за месяц и вздохнул свободно. Такое ощущение, что вышел из душной комнаты на свежий воздух.
Но потребности в большей управляемости и прозрачности, которые привели меня к потере нескольких десятков тысяч долларов и почти года жизни на игру в 1С, остались. Нужно было решение. 1С уже тогда была монополией и альтернатив не было.
Да, кстати, решится на откат ситуации было очень сложно. Я так понимаю, что большинство втягиваются навсегда.
Мое решение было экстраординарным. Я вошел в состав учредителей софтверной компании, которая делала софт, на котором я работал. И стал диктовать нужные мне решения. Ничего не получилось.
Потом создал свой проект и свою команду разработчиков. В результате основным моим бизнесом стала разработка ПО для автоматизации бизнеса. Хотя обычный земной малый бизнес продолжает работать и я даже создаю новые направления, но операционным управлением не занимаюсь. Все мое время посвящено направлению автоматизации бизнеса, а особенно управленческого учета.
Эта часть моей истории позволила взглянуть на 1С изнутри рынка, а не как потребитель.
В принципе кто-то может сказать, что я типа стал конкурентом 1С. Нифига подобного. нет никакой конкуренции. В России 1С для малого и среднего бизнеса - это среда обитания, как и для всех компаний, которые хотят зарабатывать на автоматизации малого и среднего бизнеса.
У нас нет рынка автоматизации, а есть рынок 1С. Это надо понять. Какой смысл критиковать состав воздуха земной атмосферы, которым мы все дышим?
Вопрос почему Нуралиевы смоги создать такую монополию и как?
Описанный в статье аргумент - это плюс к десяткам других более ранних аргументов.
В первую очередь 1С - это первые 10 лет лучшее решение по фискальному учету, который нужен на всех предприятиях. Это ядро и вход в рынок.
Это платформа! Платформа, на которой идет разработка прикладных решений и она сама эти решения исполняет. Т.е. чтобы изменить программу не надо выпускать новую версию. изменили код, перезапустили и обновления применились. Идея платформы для автоматизации бизнеса очевидна, поскольку все бизнесы разные и ситуация и бизнес-процессы постоянно меняются, то автоматизацию постоянно надо подкручивать под эти изменения. Это очевидно и правильно. Доказательства? Пожалуйста. Тройка мировых лидеров ERP - это платформы. А микромягкие, чтобы выйти на этот рынок купили аксапту, которая до этого выкупила своего конкурента навижн. и та и другая - это платформа.
1С - это партнерская сеть (франчайзи тут только в качестве названия). И вот идея этой партнерской сети была первой и самой мощной. (Это произошло, когда Нуралиев, внедряя вроде Лотус, слетал в холодную Сибирь, прилетел обратно, а ему звонок, что надо возвращаться, другой клиент его хочет. Там был местный который ему помогал. Нуралиеву возвращаться не очень хотелось. Он позвонил этому местному и предложил ему за 50% сделать этот проект на месте. Все получилось и это был прототип современного 1С партнерства). Ключевым элементом этой партнерской схемы является возможность зарабатывать! Те же постоянные недоработки конфигураций - это банально возможность зарабатывать партерам 1С (платформенность тут пришлась кстати). десятки тысяч партнеров постоянно делают одно и тоже для сотен и тысяч клиентов и получают за это прибыль. Идея "дай партнеру заработать" сработала на все 100. Хочешь зарабатывать на автоматизации? лучший способ - это стать партнером 1С и заниматься продажей лицух 1С и постоянными доработками. Тут даже про внедрение особо речи не идет. Самые красавцы в этой армии - это первый бит.
Ситуация замкнулась сама на себя. Большинство спецов, которые специализируются на автоматизации - это одноэсники, среди который реальных айтишников, программистов, руководителей проектов автоматизации, однозначно меньшинство. Большинство - это люди которые вошли в айтишку и автоматизацию исключительно со стороны 1С. Они не могут сравнивать, потому что они больше ничего не знают. И вот что получается. Потребитель - предприниматель, директор, финдир, бух или еще кто-то, кто понимает что ему надо автоматизировать ищет специалиста, который бы ему объяснил, что лучше выбрать. Ведь это сложно функциональный вопрос, и просто погуглить не получится. Он обращается к сообществу специалистов и в подавляющем большинстве случаев попадает на человека, который ЗАРАБАТЫВАЕТ на партнерстве 1С. Что он посоветует??? То, на чем он зарабатывает! Т.е. он приведет тысячу и один довод, что 1С идеальное решение. Даже если заказчик попробует поискать альтернативы. Да пофигу, он же полюбому опять попадет на эсника. :). Если среди этих специалистов попадется не эсный айтишник, если он даже будет круто и очень круто во всем разбираться и приведет миллион доводов, а десять других будут говорить в пользу эски, то подавляющее большинство заказчиков обратятся к эске.
Тут вспоминается фильм Револьвер "Чем больше человек вовлечено в разводку, тем ее проще провернуть. Ведь не может быть, чтобы так много людей повелось ..."
В завершения этого постообразного комментария хочу сделать вывод. Время идет и ситуация меняется. сейчас уже нет разработок с нуля и альтернативные предложения становятся реально заметными. Думаю совсем скоро, какой-то механизм спускового крючка сработает и вся эсная модель развалится.
Кстати по CRM Нуралиевы целенаправленно скупали стартапы, сначала битрикс, потом мегаплан ну и так далее до амо. И если это происходило на ваших глазах, то вы знаете как здоровое решение тут же заражалось вышеописанной бизнес моделью 1С. Партнеры, доработки и т.д.
Есть одно замечание. Проекты можно считать без накладных — это валовая прибыль. Кстати мы прибыльность по проекту контролируем риалтайм, поскольку таймшиты закрываются ежедневно и начисления приосходят ежедневно. Прямые типа командировочных тут же в проектах учитываются. А вот накладные типа офиса — это постоянные расходы. их к расчету стоимости времени лучше не прилеплять. Тут простая система управления через точку безубыточности. когда на графике переменные затраты пересекаются с постоянными. Спасибо за материал. И мы тоже из Питера.
Учет только движений денег не дает хорошего управленческого эффекта. Учитывать необходимо все варинаты операций. Как говорят доходы расходы «по начислению», но лучше так не говорить.
Цель — финансовое состояние (богатство). Если я контролирую сумму своего финансового состояния, то я контролирую свои финансовые цели. Финансовое состояние — это остатки денег, ценностей и взаиморасчетов на конкретный момент времени.
Зачастую достаточно вручную собирать. Всегда можно прикинуть какая ценность сколько стоит и по долгам вести записи, чтобы были остатки. Деньги — это самое простое. Раз в месяц свести этот баланс и узнать цифру финансового состояния уже великое дело. Подсознание начнет работать по-другому. Человек всегда знает где сэкономить и где подзаработать. Нужен только мотив. Если в очередной раз фин состояние будте меньше предыдущего, то это великолепный пендель для подсознания.
Анализ доходов и расходов уже кропотливое и сложное дело, чем вы великолепно занимаетесь. У меня в жизни было куча попыток, но так и не смог.
Чтобы вести такой анализ нужно учитывать все операции а не только денежные. Операция — это изменение состава финансового состояния. деньги+ценности+взаиморасчеты=финансовое положение. Каждая операция это движени из одной переменной этого уравления в другую. Всего элементов 4, поэтому таких движений может быть 16 типов. Типа если дал деньги в займы. то это Плюс деньги минус взаиморасчеты. Аналитика по каждой переменной своеобразная. Деньги — это валюта, места учета денег и статья ддс. Взаиморасчеты — это контрагент, договор и статус в котором этот контрагент взаимодействует с вами (кредитор, покупатель, поставщик и тд). Ну а у финсостояния как раз и будут доходы расходы так сказать по начислению. Например, потеряли деньги, плюс Убыток (вычит из финсостояния) минус деньги.
Сложности возникнут при приведении всех этих движений в единой денежное выражение. Но если нет валют, то не очень сложно.
Таким образом возникнет ситуация, когда учтенные операции будут проверяемы. ведь финсостояние прошое плюс все операции = финсостояние текущее, которое можно проверить вживую.
Описанная систематика называется ТМА. Разработана давно, а на компьютерную реализацию даже патент получен на изобретение. Есть готовые программные модули. Если интересно, то для людей которые умеют вот так все скурпулезно вести в учете мы предоставим все программные модули бесплатно.
На вопрос: «Сколько тебе надо времени на решение этой задачи?», ответ программиста: «От 20 минут до двух недель» — это вполне нормально.
Ненормально, когда программист, а если он хороший, то у него мозги многопоточные, сидит и тупит над одной задачей.
В этом кстати проблема скрама. На короткой иттерации мало задач, а часто одна, приходится сидеть и тупить, вместо того, чтобы заняться тем, что идет.
Бывает так. Программист сидит тупит, сроки, обещания, все сорвано, а решения нет. Занялся другой задачей, отвлекся, и вдуг пришло озарение, вернулся на эту задачу и за 20 минут все закрыл.
Я — РП, никогда не программировал, но программистов строить обычными методами типа жесткие сроки, особенно, если разработка сложная, это крайне неэффективно.
Мне нравится тема в ТОС (теория ограничений) по управлению проектами. Там важно построить Критическую цепь проекта и контроль и управление сводится к критическим нескольким точкам, а не срокам по каждой задаче.
Тема важная, поскольку считаю, что за интегрированными системами будущее. Времена больших ERP, где автоматизируются все функции в одной системе проходят. А если выбираешь лучшее решение отдельно для каждой функции, то интеграция должна быть действительно хорошо работающей.
Но не согласен я с подходом основанным на лечении симптомов.
Будет эффективнее находить ключевые проблемы, базовые причины проблем, которые на поверхности повседневной практики.
Например. Контрагенты, договоры, валюти и пр. — это просто таблицы в базе данных, хранящие набор признаков, которые используются в других таблицах, типа «проводки». Кстити Учетные счета — это тоже просто таблица. Если в двух системах есть таблица с функцией хранения реестра Контрагентов, то при консолидации будут проблемы. Но такие же проблемы будут с любыми другими справочными таблицами в базе данных.
Решение будет также одно. Например, мы предпочитаем урегулировать все несоответствия через таблицу «Правила соответствия» где просто указываются синонимы из разных баз и эта таблица учитывается при взаимодействии данных по алгоритмам. Но часто встречаю попытки сделать в холдингах единые справочники (по мне дак очень плохая идея).
Но больше всего в вопросах интеграции меня беспокоят закрытые базы данных. Разработчики считают что в структуре их баз прям вот ценность и делают так, что интегрироваться можно через их, зачастую очень кривое, API, без нормальной документации и с очень урезанными возможностями. Если базы открытые и могут запросами общаться друг с другом, то меньше проблем.
Когда Вы пишите вот прямо по конкретностям, но это становится учебником, который никто не читает. Для меня вопрос мега актуальный, но признаюсь честно, с третьего абзаца уже пошла диагональ.
Agile — изначально это возможность заказчика в ходе разработки менять требования, т.е. гибкая разработка. Модели процессов, которые придумывают люди, чтобы обеспечить такой режим разработки нельзя применять «как есть» с закрытыми глазами на текущую в конкретной команде реальность.
Получается, что в описанном результате не виноват ни сам эйджайл, ни скрам.
Если мой разработчик обнаруживает, что есть незапланированная задача, которую следует по его мнению выполнить, то он просто вносит ее. В зависимости от настройки проекта он, либо ждет согласования, либо выполняет сразу и учитывает по ней затраченное время.
На вопрос сколько нужно времени на выполнение задачи, ответ от программиста от 20 минут до 2 недель вполне приемлем! У программистов многопоточное мышление. Если он не знает, как сейчас решать задачу лучше и переключается на другую, то это не значит, что во втором потоке не идет поиски решений по первой. Надо уметь давать вызревать задаче, тогда на ее решение может уйти всего минуты. Это уже практика.
По факту хреновый был у вас менеджмент, видимо хорошего опыта разработки не имел.
Опасайтесь моделей! Модели бизнес процессов, взятые из опыта других — это лишь примеры для ваших размышлений. Принять к сведению и сделать по своему. Приблизительно такая же ситуация произошла, когда один из «наших» купил Mandriva, ввел туда менеджмент и все разработчики разбежались, а разработка была приостановлена.
Менеджмент и разработчики и много других участников процесса разработки — это части одного целого. Нельзя противопоставлять их друг другу. Причем со стороны разработчиков также нужно относится с пониманием, или хотя бы с желанием понять задачи тех, кто управляет разработкой или выполняет другие функции, в купе дающие готовый и рабочий продукт.
Много раз встречал и быстро прощался с разработчиками, которые ставили себя выше других и с пренебрежением относились к другим участникам не столь одаренным, но выполняющим свое дело. Только во взаимопонимании рождаются действительно хорошие продукты, и устанавливается комфортная среда для ведения процессов разработки. А методы должны соответствовать конкретной команде, задаче и другим условиям окружающей среды.
Всех благ.
И это без иронии. Все правильно.
Однако бизнес должен приносить доход, это прокрустово ложе для всех остальных целей собственника или инвестора. Если собственник забудет следить за этим бизнесу непоздоровится даже с великолепной командой и внутренней культурой. Поверьте :). это история про меня 15 лет назад. Целый новый рынок построил. 100 человек команда были как одно целое. Я тратил на это все свое время и это была моя жизнь, самореализация и все что угодно подпадающее под нефинансовые цели собственника. Но потом был конец этой сказки и подавляющее большинство команды оказались людьми способными быть нормальными только когда все цветет и пахнет. Такова природа людей и не виню их в этом. Вот следить за тем, чтобы все цвело и пахло надо было самому и это все моя ошибка. Может поэтому много лет занимаюсь этими вопросами с такой серьезностью. Так сказать палец в розетке побывал. Плавали, знаем.
Понимаете. Не могу спорить с тем, что Вы пишете. Это истинная правда и про это нужно думать и говорить. Но если Вы собственник, все же не забывайте про основную работу, следить за доходностью! И это не распределение бюджетов, это экономика, т.е. экономический прирост бизнеса должен быть всегда!
Про это и речь была в статье, а не за доход непосредственно собственника, пассивный и растрачиваемый на замки и массажистов жены.
Спасибо Вам за внимание к этой теме.
Если хотите обсуждать идеи, то не стесняйтесь пишите на электронку или в личку, Правда я тут теперь редко бываю.
Я бы сказал в этом цель. Иначе зачем делать бизнес. А вот забывать не надо. О том и речь в статье. Как сохранить пассивность дохода и не терять контроль.
По поводу репрессивного аппарата не соглашусь совсем. Все зависит от бизнеса. Существуют различные методы мотивации и в разных случаях одни вредят другие помогают. Панацеи, заставляющей людей работать не думая о личном времени с полной отдачей не существует. Это как практик говорю. Со временем пришлось научиться понимать как и с кем нужно обращаться, чтобы мотивировать. Хотя подавляющее большинство любит плетку :), в этом ваша правда.
По поводу «выделил бюджет». Это один из примеров «других методов», которые я приводил в этой статье.
Спасибо за комментарий. Не думал, что эту статью еще кто-то читает. В знак благодарности еще раз обращу ваше внимание на то, что в статье пропагандируется взгляд на бизнес «сверху вниз», от общей картины к деталям, и немного раскрывается методика. Но это слишком мало, чтобы раскрыть всю проблематику.
Проблема, как сделать доступным в МСБ то, что в крупном ключевые вендоры дают за большие деньги крайне актуальный. И эти вендоры надо сказать очень этот вопрос думают, правда не лучшим образом получается.
Мы тоже создали свою платформу и системы для анализа, только решаем вопрос не моделирования, а фактического учета и отчетности. И ровным счетом также замещаем эксель в этих вопросах в сегменте МСБ и пытаемся сделать все это доступным.
Вопрос доступности заключается не только в технологической, но и в методологической составляющей, причем обе части тесно взаимосвязаны.
Получается, что Вам надо не просто дать инструмент вместо экслея, но вложить в него понятную простым малым предприятиям методологию анализа, планирования и моделирования.
Насколько я понял, Вы как раз специализируетесь на этом, поэтому такое будет для Вас возможно.
Приведу пример.
В одной консалтинговой компании клиент заказал автоматизировать финансовую модель по проектам строительства многоквартирного дома. Они четыре месяца ваяли на икселе и свояли два файла по 30 мб. Монстры. Смогли даже сдать работу и получить немаленькие деньги, но при этом хватило ума понять, что так делать нельзя. Стали искать разработчиков, кто бы этоу финансовую модель сделал бы в нормальной архитектуре, понимая, что это будет типовое решение, которое потом можно продавать подобным застройщикам.
В этом решении будет две составляющих. Одна — это непосредственно разработанная консалтерами модель, а другая — это сама программа.
Вот используя этот пример пытаюсь объяснить, что надо спускать в доступном виде в МСБ.
Мы делаем доступные методы счетоводства, тоже потратили годы и вроде бы начинает получаться.
Есть желание, давайте делиться друг с другом опытом в достижении цели дать доступные, но полноценные инструменты для МСБ в учете, анализе и моделировании, замещая иксель, который до определенного момента замечательный инструмент, но когда упираешься в потолок, то проблемы утраиваются.
Мы хорошо знакомы с автором этой статьи, но на поставленный вопрос отвечу однозначть ДА! Стоит. И тут смысл не в том, как пишуться цифирки и по каким счетам и в каких формах. Теперь это вообще дело иное. Езерский разрабатывал систему учета с использованием качественно иного носителя информации (бумага), чем тот, что используется сейчас.
Стоит возраждать саму идею Езерского.
По этому поводу стоит процетировать Соколова:
«Русская форма была создана в 1869 году в Дрездене. Ее создатель — русский бухгалтер-самородок Федор Венедиктович Езерский (1836-1915) — думал, прежде всего, не о том, как лучше расположить регистры и как проще работать счетоводу-бухгалтеру.
Он пытался решить главную задачу управления: отслеживать в реальном масштабе времени успешность работы предприятия. Дело в том, что все предприниматели во всем мире до сих пор, как это ни парадоксально, работают „вслепую“, то есть финансовый результат может быть установлен только после составления баланса.»
Подробнее: buh.ru/articles/documents/13508/
Официальная бухгалтерия, налоговый учет, МСФО работают в требованиях установленых правил. Так им надо. Но кроме всего этого есть собственники и управленцы, которые в гораздо большей степени заинтересованы в учете. В том, чтобы он был понятным, прозрачным и давал понятную общую картину успешности (состояние и результаты деятельности) и желательно в масштабе реального времени. Сейчас это принято называть Управленческий учет.
Вот именно в этом направлении стоит присмотреться к идеям и целям, а так же всем действиям этого великого русского бухгалтера. Мало кто в мире среди профессиональных бухгалтеров настолько хорошо понимал потребности самого бизнеса в учете и предпринимал бы такие масштабные действия по практической реализации своих разработок. Все это делается лишь с одной целью, позволить бизнесу быть лучше. Для этого учет и должен существовать и развиваться, а установленные правила регламентного учета, не важно русского, европейского или американского формата, пусть остаются правилами, нельзя на них слепо ориентироваться в бизнесе.
У меня есть мнение, что в России есть определенный смысл возрождать дело Езерского, ведь прозрачность бизнеса, которую дает хороший учет, который строится на хороших системах и ведется хорошими образованным специалистами, дает бизнесу возможность нормального взаимодействия со своими инвесторами, поставщиками, клиентами, сотрудниками и прочими в действительности внешними сторонами. Так же хороший учет дает возможность качественных обоснованных управленческих решений, а так же их тестирование на общем результате.
Чтобы получить хороший учет, нужно создвать системы (на подобе той, что создал Езерский, только в свое время), заниматься образованием собственников, управленцев и учетных работников (как это делал Езерский, только в свое время), обеспечивать информационным потоком эту отрасль, чтобы было всем понятно, о чем идет речь (как это делал Езерский, издавая множетсво относительно простых книг и журналов), и наконец поменьше смотреть в сторону «за бугор» (как это дела Езерский), поскольку большинство приемов тамошних может просто не подходить для наших реалий.
Вот именно поэтому стоит возраждать дело Езерского и возможно его имя использовать как знамя для возраждения направления русской, понятной и эффективной бухгалтерии в сфере управленческого учета.
Хочу исправиться, объяснить и обосновать свою позицию.
1. Я действительно отождествляю финансовый и бухгалтерский учет. Определений этих терминов в учебиках и в интернете много. Общепризнанный факт, что единого смысла этих определений нет, очень много разночтений. Именно поэтому я обращался к основам происхождения этих терминов. Финансовые учет нацелен на создание фин отчетов, тут мы согласны друг с другом. Финансовым называется, поскольку основан на выражении данных в измерении той или иной денежной (финансовой) единицы. При чем формы имеют устойчивый вид (баланс ОДР ОДДС). Что касется бухгалтерского учета, то БУХ — это книга, или по нашему счет учета. Если дословно, то бухгалтерский учет — это ведение книг (счетов) учета. Система ведения счетов учета (счетоводство, или форма счетоводства) направлена на единственную цель, сфомировать финансовые (бухгалтерские) отчеты. От сюда мы получили полное идинообразие целей а соответственно понимание, что финансовая система и бухгалтерская система это синонимы по смыслу. У той и другой на входе первичка, а на выходе фин отчеты. А вот сужать фунцию бух учета до сбора первички по моему мнению не является корректным, видимо это дань определениям из учебников. Именно наука бухгалтерского учета породила больше ста лет назад понятие балансоведение, а баланс — это главный из финансовых отчетов. Но общее мнение современного обывателя отождествляет бухгалтерский учет с процедурами согласно установленному законодательству, причем в интересах государства. Хотя самые великие умы бух науки современности, примеру, Соколов (младший) до сих пор полагает, что бух учет — это для собственника. Чтобы отделить этих мух от котлет я и постарался заключить понятие бух учета в процедуры связанные со стандартами, и конечно не только в нашей стране. Налоговый учет — это тоже самое, только немного правила проведения по счетам отличаются. В основе и финансового и бухгалтерского и налогового учета лежит родовое понятие счетоводство. К сожалению оно подзабыто. Надеюсь теперь я свою позицию объяснил.
2. Управленческий учет. Если с прошлыми понятиями еще как-то можно разбираться, то с этим вообще не реально. Маломальский стандарт существует только в америке. В нашей стране за это понятие идет война между кафедрой бух учета и кафедрой финансового менеджмента. Они там бадаются по поводу того, кто должен учеть всему тому, что к этому понятию относится. И учат совсем поразному. Хотя, между нами, надо просто принять факт, что управленческий учет — это все то, что надо управленцу для принятия решенй. Что я в статье и утверждаю. У меня очень большой опыт управления. Обобщить и унифицировать требования к упр учету по отношеию к фин учету был непросто, но то, что вы видите это голая практика. Согласитесь, что в таких системах координат хотябы можно дальше мыслить безотносительно всего того, что понаписано различными авторами в различных учебниках. Задача стояла представить ключевую суть, а не создать очередное определение. Большинство любей живет по определениям, тут сложно спорить. Это большинство правильность определяет через сравнение с известным шаблоном, на котором написано «правильно» (Д.Э.Н. Иванов И.И.). Я по природе своей отталкиваюсь от сути. ИТ сообщество отличается тем, что большинство из них, все же, так же отталкивается от сути и способно строить довольно длинные цепочки причинно следственных связей (я имею ввиду программистов). Поэтому в статье идет выстраивание базовой сути, простой и взаимосвязанно обоснованной. Причем идет оговорка, что установка этой базы не претендует на формирвоание определний, а нужна лишь для правильного понимания дальнейшей информации, где в описании будут использоваться эти термины.
Но за последние три года на рынке возникли интересные тенденции. Управленческим учетом стали называть системы, где формируется управленческий план счетов и ведется двойная запись, а результатом являются финансовые отчеты по упрвленческому плану счетов и внутрикорпоративным стандартам (первый бит управленческий учет или Финград). Финград кстати использует довольно продвинутые алгоритмы электронного счетоводства.
3. МСФО и ГААП — это такие же бухгалтерии, как и РСБУ (я дипломированный бухгалтер по МСФО). Кстати за последние 10-14 лет рсбу очень сильно сблизилось с мсфо. Бухгалтерии в вышесказанных понятиях. Но надо отдать должное, что эти стандарты ближе к интересам собственников и не заключают в себе исключительно интересы государства. Все эти заявления категоричны и являюстя крайностями. Я встречал на практике варианты бизнеса, когда бух учета было вполне достаточно, чтобы удовлетворить упр цели, и обратную картину тоже встречал. Что дает возможность утверждать, что в том виде, в котором ведется бух учет сейчас, для целей управлеия не пригодный. Т.е. есть варианты, что его никак не приспособить, но есть и варианты, когда возможно.
4. Что касается отчета о капитале, то этот отчет является требованием стандартов. В рамках предлагаемых мной методик он не имеет такого выделенного смысла. В пассиве баланса я предлагаю вести раздел собственный капитал, где формируется статья вложенный капитал (с начала времен), изъятый капитал (с начала времен), накопленная прибыль (с начала времен), накопленный курсовые и стоимостные дельты. Сумма этих статей дает сумму собственного капитала. Это лишь подход, который предлагает Цыганков, а мне очень нравится, как собственнику бизнеса. Но это лишь подход. Можно лего формироать отчет о распределении прибыли если таковая есть или по капиталу, плюс систему финансовых показателей. Все это вторично.
Ладно, много написал. Основные разногласия, что для вас бух — это первичка, а для меня счетоводство, у которого эта первичка есть вход. На базе того, что великолепно знаю историю бух учета в деталях, думаю мое утверждение будет более корректно, особенно если рассуждать про алгоритмы автоматизации процессов построенния фин отчетов.
Еще раз прошу прощения за грубость в прошлых комментариях. Я вижу, что Вы специалист и хорошо разбираетесь в теме, просто тема эта неоднозначная.
Учитывать траты, доходи и расходы сложно, это точно. А вот состояние учитывать нет проблем, даже программ не надо. Ссылка на статью
Только маленькая корректировка. Сами программисты зачастую далеки от специальной области, где должна проводиться автоматизация. Сами они такого понаворотят….это уже проходили. Но то, что подобные концепции должны делаться с полным пониманием всех основ программирования, баз данных и с хорошим опытом управления разработками, согласен на все 100.
Для разработки мостик взаимопонимания должен быть построен между программистом и специалистом в требуемой области, а это ооооочень сложный вопрос.