У Google с Apple бизнес, который выгоден самой Google (о чем говорит и Ваша ссылка), а с Mozilla — благотворительность, оформленная под видом коммерческого договора.
И еще один момент. Я не являюсь противником Mozilla, так как сам еще десять лет назад реализовал крупный корпоративный проект на более чем 1000 пользователей, в котором веб-клиентом был именно Firefox как единственный браузер на тот момент, поддерживающий современные веб-стандарты.
Но со временем оказалось, что все больше пользователей и разработчиков стали самостоятельно переходить на Google Chrome из-за удобства самого браузера и скорости работы JavaScript. На сегодня единственное, что сдерживает от окончательного перехода на Chrome (или на аналогичные браузеры), это менее удобно реализованная печать бумажных документов в Chrome по сравнению с Firefox, которая все еще остается крайне важной функцией в корпоративных приложениях.
Возможно Вы и правы. Но вот лично мне очень сложно представить противостояние слабого сильному, который к тому же и кормит этого слабого. Такое поведение обычно обозначают как «кусать кормящую руку». Если же действия Mozilla действительно характеризуются как противостояние, а не, например, участие в процессе выработки новых стандартов, то у такой компании нет будущего по определению, так как никто в здравом уме не захочет работать с такой организацией.
Mozilla посредством своего браузера Firefox в свое время противостояла неадекватному поведению Microsoft, которая плевать хотела на веб-стандарты и пыталась навязать обществу свое видение интернета через IE (чтобы затем зарабатывать на своем монопольном положении). Как только Microsoft одумалась и начала придерживаться общепринятых веб-стандартов, с этого момента исчез смысл существования браузера Firefox. И то, что Google довольно долго поддерживала Mozilla, обусловлено исключительно жалостью к бывшему соратнику по борьбе с Microsoft за продвижение общепринятых веб-стандартов.
Одно из качеств умного работника: сколько раз работник сможет неправильно перенести мешок таким образом, чтобы результат его переноски принудил бы его альтернативно одаренного начальника к уточнению технического задания по переноске мешков.
Ок. Попробую по-другому. Большинство прикладных программных продуктов можно написать с минимальным количеством собственных интерфейсов и абстрактных классов, при это вовсю используя разработанные другими людьми интерфейсы, такие как jdbc или http.
Так вроде бы ответ на Ваш вопрос уже сформулировал ранее? Нет? Цитирую: «Разработка абстракций оправдана лишь либо в случае явной потребности в последующем масштабировании программного продукта, либо в случае возможности использования разработанных абстракций в других проектах».
Под термином «масштабируемость» как раз и подразумевается массовость производства в сфере разработки ПО. В зависимости от специфики ПО масштабировать можно по количеству пользователей, по объему данных, по объему вычислений, по количеству разрабатываемых проектов, по скорости адаптации программного кода под внешние условия и т.п.
Ну а для поддержки и доработки кода важно качественное проектирование структуры приложения, грамотная работа со структурами данных, разумное разбиение кода на отдельные процедуры, внятное документирование кода и т.д. и т.п. При отсутствии же потребности в масштабировании грамотно написанный код вполне себе можно разместить в одном слое без всяких дополнительных абстракций.
Все эти абстракции нужны лишь для одного — уменьшить себестоимость производства массового продукта. Для уникальных же продуктов абстракции ведут лишь к удорожанию продукта, особо не влияя на качество, при этом растягивая сроки его реализации.
Ведь для разработки качественных абстракций также нужно потратить определенное количество труда и разных ресурсов. В примере с домом используются ранее разработанные другими людьми абстракции (стандартный кирпич с определенными характеристиками). А что если взять пример по разработке дома из деревянных бревен (не путать с брусом), размеры каждого из которых уникальны сами по себе, а характеристики зависят от сезона и места заготовки?
Здесь уже придется разрабатывать собственные абстракции, такие как технологию обработки древесины, способ укладки сруба, выбор отделочных материалов и т.д. А это значит проектирование, документирование, обучение сотрудников и т.д. Для разового проекта это не нужные дополнительные затраты, а вот в массовом производстве домов из бревен созданные ранее абстракции помогут снизить затраты, повысить качество и ускорить сроки строительства.
Так и в разработке программных продуктов. Разработка абстракций оправдана лишь либо в случае явной потребности в последующем масштабировании программного продукта, либо в случае возможности использования разработанных абстракций в других проектах. Разработка же абстракций ради хождения по ним является запудриванием мозгов заказчикам и партнерам по разработке, которая повышает риски снижения потребительских качеств продукта, его удорожания и оттягивания на неопределенную перспективу сроков сдачи продукта в эксплуатацию.
Лучше всего на обозначенную автором тему сказал Мартин Фаулер: «Любой дурак может написать код, который будет понятен компьютеру. Хорошие программисты пишут код, понятный другим людям».
Иначе говоря, в реальной работе нужно выбирать те инструменты и технологии, которые используют окружающие тебя люди, ну или, по крайне мере, самые профессиональные и опытные из них.
Очередной пример, когда категоричные утверждения ярко раскрывают личность самого утверждающего.
Во-первых, связывание языков программирования (PHP и JavaScript) с уровнем профессионализма пишущих на этих языках свидетельствует о низком профессиональном уровне автора и его окружения, так как современный уровень развития этих языков позволяет писать на них качественные приложения промышленного масштаба.
Во-вторых, автор не рассматривает такой вариант демонстрации неграмотной речи, как проверку навыков самого кандидата по формализации нечетко сформулированного технического задания. Это свидетельствует о том, что автор является представителем самой низкооплачиваемой категории разработчиков, которые способны только на выполнение четко сформулированных задач.
В-третьих, автор даже не рассматривает наличие не очень образованного и не очень умного начальника в качестве возможности получения опыта или карьерного роста. Это свидетельствует об отсутствии у автора здоровых амбиций и желания учиться, что может означать, что такого специалиста нужно постоянно контролировать и подпинывать даже при решении самых простых задач.
Все это свидетельствует о том, что для автора гораздо важнее не то, что нужно делать, а в каких условиях это можно делать. То есть для него важнее шашечки, а не ехать. Ну а нужен ли такой специалист в команду, каждый может решить сам.
P.S.: В дополнение картинка на тему профессионального сленга:
Ок. Поясню свои тезисы. В учете за счет того, что руками вводятся преимущественно абсолютные показатели, а относительные рассчитываются, можно использовать относительно простые схемы базы данных, а вычисления выполнять прямо в самой базе данных простыми sql-запросами. Например, при сохранении данных счет-фактуры в базу данных заносятся показатели выручки на весь объем, даже если в базе данных есть прейскурант цен и количество в натуральных единицах. В результате сразу после ввода данных счета-фактуры можно сформировать свод по реализации, в котором уже расчетным путем получить средние цены в различных разрезах. Это становится возможным, так как после заключения договора и отгрузки продукции ни цена, ни объем этой отгрузки не меняются.
В планировании все наоборот. И цена, и количество являются переменными величинами, которые могут постоянной пересчитываться вплоть до утверждения плана в окончательной редакции. При этом ни количество, ни цена не могут быть быть агрегированы в лоб, так как цена является средневзвешенной величиной, а количество может иметь разную размерность, а потому сумма количеств в большинстве случаев является бессмысленной величиной (например, сложение метров и килограммов). В результате для расчета плановой суммы продаж, равной произведению количества на цену, нужно для каждой позиции предварительно рассчитать это произведение, и лишь затем производить расчет общего итога. А так как и цены, и количества продукции могут быть изменены в любой момент, то такие расчеты должны производится в режиме реального времени. То есть следствием такой схемы расчета является гораздо более высокая сложность и ресурсоемкость плановых расчетов по сравнению с фактическими при агрегации даже обычных стоимостных показателей.
Что касается расчета плана сверху-вниз, то если на каком-то уровне такая схема не превращается в планирование снизу-вверх на основании норм и цен, а представляет собой лишь подгонку детализирующих лимитов под спущенные сверху сводные лимиты, то такое планирование является обычной профанацией. Поэтому такую схему нет никакого смысла рассматривать всерьез. Ведь в процессе планирования важно не только рассчитать сводные финансовые результаты, но и понять влияние на эти сводные результаты отдельных факторов, которыми как раз и выступают удельные нормы расхода, ставки, цены, различные нормативные коэффициенты и т.п. Влияние таких факторов на сводные результаты определяется путем проведения факторного анализа, выполняемого, например, методом цепной подстановки.
Что касается уровня регламентации, то здесь важно то, что нормативная база представляет собой по своей сути качественное техническое задание, содержащие в себе не только конечные формы отчетности, но и детальную регламентацию различных учетных процессов. В такой ситуации любой разработчик способен разработать программное обеспечение для бухучета, даже особо не разбираясь в его специфике.
В процессе же планирования, в котором вся исходная нормативная база и алгоритмы расчета целиком и полностью завязаны на технологические особенности организации, для разработки качественного программного обеспечения для стороннего разработчика практически нет качественных источников информации для разработки технического задания. Поэтому сегодя любой программный продукт для планирования представляет собой либо универсальную электронную таблицу типа Excel, либо некоторый полуфабрикат, который требует доработки под специфику организации с помощью консультантов за довольно большие деньги. Плюс доработка такой специфики осуществляется с использованием языков программирования, которые не доступны для самостоятельного освоения большинством экономистов-плановиков.
На тему того, что информация в процессе планирования ходит по кругу между отделами, Вы не только не опровергли мой тезис, но и сформулировали дополнительное отличие учета от планирования. Которое заключается в том, что при учете сотрудники функциональных службы в рамках учета лишь однократно вводят информацию, за которую несут ответственность (например, заполняют фактурную часть счета-фактуры). Бухгалтерия же после этого заполняет недостающие атрибуты первичных документов. При планировании службы не просто вводят информацию, которую затем используют плановики, но и периодически ее уточняют и дополняют, причем зачастую письменно обосновывая необходимость тех или иных изменений. В результате плановики не просто обсчитывают экономические показатели по всем процессам предприятия, но и интенсивно взаимодействуют с отделами-поставщиками исходных данных для плановых расчетов.
Учет и планирование отличаются не только направлением трансформации данных (снизу-вверх или сверху-вниз), но и рядом других, в том числе:
1. Принципом отнесения данных к первичным (вводимым руками) или расчетным (вычисляемых компьютером). В учете первичными данными выступают преимущественно абсолютные значения показателей (количество потребляемых ресурсов, суммы продаж, суммы процентов по кредитам и т.п.), а в планировании — преимущественно относительные (нормы расхода потребляемых ресурсов, цены продаж, процентные ставки по кредитам т.п.).
2. Учет всегда оперирует фактической информацией, которая является максимально полной и достоверной. При этом план всегда оперирует будущей информацией, которая по определению всегда недостоверна и фрагментарна.
3. Уровень детализации в учете и планировании определяется возможностью контроля руководителей организации за качеством управленческой информации. В учете, который оперирует фактической информацией, возможен контроль на уровне каждой хозяйственной операции, оформляемой первичным документом. В планировании, оперирующим информацией о будущем, контроль возможен только на уровне укрупненных статей, так как излишняя детализация планов лишь повышает степень их неопределенности.
4. В учете в подавляющем большинстве случаев используются последовательные расчеты вычисляемых показателей. В планировании зачастую невозможно обойтись без рекурсивных расчетов.
5. Учет представляет собой строго регламентированный процесс, регулируемый нормативными актами начиная с федеральных законов и заканчивая внутриведомственными инструкциями и стандартами. Для планирования отсутствует какая-либо регламентация со стороны государственных органов (за исключением государственных учреждений в рамках бюджетного процесса), в внутри организации процесс планирования в гораздо большей степени регулируется сложившимися практиками, чем внутренними нормативными актами.
6. Учет представляет собой периодически повторяющийся и практически не меняющийся со временем процесс с временным лагом в один месяц. Планирование больше всего похоже на проект, который выполняется один раз в год (для годового планирования) каждый раз в новых условиях (факторов внешней среды) и с новыми критериями эффективности (целями высшего руководства).
7. Учет в средних и крупных организациях, как правило, разделен на несколько однотипных процессов (материальный учет, финансовый учет, кадровый учет, учет основных фондов, налоговый учет и т.п.), который ведется узкоспециализированными сотрудниками (кадровик может не разбираться в налоговом учете и наоборот). В планировании работы в рамках всех процессов выполняется одними и теми же сотрудниками, обладающими знаниями по всем планируемым процессам организации. Малые предприятия несколько выпадают из данной классификации — в них обычно весь учет ведет один главный бухгалтер, а планирование как таковое вовсе отсутствует.
Указанные факторы, несмотря на довольно большое сходство итоговых документов в учете и планировании, приводят к невозможности использования учетных программных продуктов в процессах планирования. А где это делается, там эффективность планирования в лучшем случае стремится к нулю, а в худшем — вводит в заблуждение руководство организации об экономической эффективности их собственных планов. По этой причине подавляющее большинство организаций для планирования используют MS Excel, даже при наличии у них эффективной автоматизированной системы учета.
В качестве представителя не указанного в статье класса систем, предназначенных для автоматизации системы бюджетирования и управленческого учета, можно привести платформу экономического моделирования JetCalc. На Хабре опубликованы следующие статьи про JetCalc:
Вы правильно отметили, что Scrum и Agile — это всего лишь методики, которые без качественной образовательной базы являются всего лишь инструкциями с картинками к сложным устройствам для начала работы. И максимум, что можно ожидать от таких инструкций, это быстрое знакомство с правилами работы и техникой безопасности, которые позволяют начать работу, но совершенно не предполагают получение даже минимально полезного результата.
Например, возьмем инструкцию по эксплуатации бензопилы Husqvarna. В ней описаны и устройство бензопилы, и техника безопасности, и основные приемы работы, и техническое обслуживание бензопилы. Но наличие этой инструкции совершенно не гарантирует, что в реальном лесу конкретный лесоруб не опилит себе ногу или руку этой бензопилой по собственной дурости просто потому, что пошел валить деревья бухим (или сонным, или на нервах, или ...). Но зато наличие такой инструкции не позволяет пострадавшему предъявить претензии к производителю бензопилы для возмещения ущерба за отрезанные руки или ноги.
Scrum и Agile — это своеобразные комиксы для людей с короткой памятью и неразвитым мышлением, которые не способны прочесть до конца и понять даже стандартные учебники по теории систем, организационному управлению, психологии и т.п. А потому любой умный программист всегда подберет для самого хитрого скрама наиболее подходящий болт.
То есть исходя из буквальной трактовки термина «абсолютная ценность» можно предположить, что воля и интеллект лично для Вас являются менее значимыми ценностями, чем свобода? Что Ваши личные цели и средства их достижения в гораздо большей степени определяются внешними обстоятельствами, определяемыми некоторым уровнем свободы, чем Вашими личными волевыми качествами и уровнем развития Вашего интеллекта?
Если это так, то чем тогда Ваши представления о свободе отличаются от красивых проектов Обломова? Лично для меня — абсолютно ничем. В своей жизни я наблюдал сочетание абсолютной свободы в отсутствии воли и интеллекта только в виде вульгарных шествий извращенцев в костюмах проституток плечом к плечу с проститутствующими (по необходимости) политиками и проститутствующей (по призванию) богемой. Счастье, что только по телевизору.
Друзья, на моих глазах запороли две перспективные компании из четырех федеральных, в которых мне довелось поработать. В лучших традициях моих рассказов, весело и с матом я расскажу как можно всадить любой перспективный бизнес за максимально короткий срок.
До веселой матершинины нужно прояснить два момента. Первый — зачем в компании нужны политики и процедуры? Вы не знаете? Чтобы их исполнять? Да перестаньте! Политики и процедуры создаются, чтобы заменить незаменимых. Это просто стадия жизни компании от хороших специалистов до хороших политик и процедур. Следующий этап жизни компании: засирание нереализуемыми политиками всего поля принятия решений, локальных ресурсов и главное — изъёбывание всем мозгов.
Второй момент — почему в ответственные моменты на ключевые позиции часто назначают мудаков? В среднем по автобусу их и так дохрена, но раньше они не могли себя проявить полностью. В критические моменты все становится очевидно.
Если перевести мою статью на английский и закинуть в google, то наверняка найдется пуля в пулю такая же методичка. Ну не могут дураки придумывать одинаковую ху… ю с точностью до ноты!
Итак, как запороть компанию!
Правило 1: снеси всех адекватных топов, но не трогай дураков. Дураки этого хода не поймут, но будут все время тебе в рот заглядывать и рассказывать всем какой гендир мудрый и вообще пиздатый;
Правило 2: прими нереальный бюджет. Даже акционеры должны ох… ть от твоих обещаний. В итоге выручка год к году +30%, расходы -30%. Бюджет должен всех разумных менеджеров бросить в мороз-понос. Слабые бюджеты для сопляков, устрой этим сучкам новый 37-ой год;
Правило 3: сократи 10-15% штата. Неси любую ересь про неэффективный балласт, тенденции ведущих компаний, автоматизацию и роботизацию. Лучше приводить в пример американские компании, там всегда липко-сладкие истории для дебилов;
Правило 4: демотивируй всю компанию пересмотром премий, соц.программ и любых льгот. Если была сотовая связь, зарежь ее для большинства сотрудников или уменьши компенсацию в три раза. Пойми — они зажрались! Кто не хочет, может искать другую работу. Ты легко наберешь на рынке свежих долбоебов из другой сферы, без нужного опыта, но преданных как немецкая овчарка;
Правило 5: сообщи всем сотрудникам, что в компании тяжелые времена. Это даст тебе еще гамму ебанутых ходов и развяжет руки;
Правило 6: парализуй перемещение и найм сотрудников. Вместе с сокращением штата это классный метод убить целые направления работы: растерять корпоративных клиентов, ключевых поставщиков, задрочить преданных менеджеров;
Правило 7: перекрои всю штатку, объедини пару дирекций, самые активные подразделения рассели в разные корпуса, желательно в разных районах города. Если система вдруг заработает, то ты молодец. Если не заработает, то эти говнюки саботируют процесс;
Правило 8: передай управление бизнесом службе HR. Запомни, шеф, эти сраные начальники направлений всегда хотят больше людей, чтобы эффективнее работать. Покажи, что эти недоумки тут не главные. Вместе с контролем численности пусть бизнес обосновывает необходимость найма кадровикам. Не путай: не HR для бизнеса, а бизнес для HR!
Правило 9: режь косты! Не сокращай затраты, а именно режь и именно косты. Под этим мероприятием можно понимать любую хрень. Покупай бензина в два раза меньше обычного, не заказывай офисные принадлежности и бумагу для принтеров. Никакой туалетной бумаги Tork! Оцинкованное ведро в углу в лучшем случае;
Правило 10: придумай ебанутые KPI. Например, «из каждого килограмма досок должно получаться два килограмма скворечников». Как? Да это не твое дело! Пусть думают и лучше работают, бездари. Могут использовать больше гвоздей или собирать со скворцами уже внутри;
Правило 11: заморозь всё перспективное развитие. Нельзя ничего развивать, когда у компании тяжелый период. Даже жизненно необходимые проекты могут подождать твоего золотого парашюта;
Правило 12: внедри новую систему отчетности. Это позволит тебе запутать руководство еще на пару месяцев;
Правило 13: тащи в контору именитых консалтеров, лучше бы из совершенно другой сферы. Если твой бизнес — не FMCG, то консалтеры должны быть именно оттуда. У них все просто: склад-полка-покупатель. А ты же так и делаешь! Всей кучей можно втирать очки до последнего.
И запомни главное, не ты плохой, просто ты гораздо умнее этого мяса. В конце концов, у тебя же есть MBA и диплом какого-нибудь американского ВУЗа, в котором ты никогда не был. Если когда-нибудь дрогнешь, вспомни, что Google переводит сотрудников на home-office, а Цукерберг обещает запускать дирижабли с Wi-Fi в пустынях. Ну неужели ты на работе не сможешь нести такую же ху… ю?!
Не нужно путать память и мышление. Это хоть и взаимодополняющие вещи, но никак не взаимозаменяющие. Одно дело — услышать чужую мысль, запомнить ее, а затем использовать как свою. И совершенно другое дело — услышать чужую мысль, критически ее переосмыслить, сделать выводы, которые и запомнить, чтобы использовать в дальнейшем.
Свобода воли может быть только там, где есть преодоление собственной боли или страха в достижении собственных же целей. Все остальное — это либо случайный выбор из множества доступных вариантов, либо исполнение чужой свободной воли.
И человек изначально рождается абсолютной несвободным. И только со временем лишь считанные единицы становятся по настоящему свободными, постепенно беря под контроль свою боль и свой страх. Для большинства же припасена красивая сказка о наличии у них свободы воли, которая разбивается на мелкие осколки при первом жестком соприкосновении с действительностью, равнодушной к чьей-либо воле.
Свобода слова – это действительно важная вещь. Но свобода слова является именно свободой только тогда, когда основана на свободе мысли.
Мысли же могут быть свободны только у людей, которые способны их самостоятельно сформулировать, а не заимствовать у других людей. Ведь свобода навязанных мыслей аналогична свободе перемещения в пределах тюремной камеры в определенное время суток.
И здесь возникает вопрос: может ли быть свободным слово, основанное на несвободных мыслях? Ответ на мой взгляд однозначен – не может. Поэтому людей, которые говорят о свободе слова, транслируя без переосмысления чужие мысли, можно в лучшем случае назвать демагогами, а в худшем – провокаторами.
И еще один момент. Я не являюсь противником Mozilla, так как сам еще десять лет назад реализовал крупный корпоративный проект на более чем 1000 пользователей, в котором веб-клиентом был именно Firefox как единственный браузер на тот момент, поддерживающий современные веб-стандарты.
Но со временем оказалось, что все больше пользователей и разработчиков стали самостоятельно переходить на Google Chrome из-за удобства самого браузера и скорости работы JavaScript. На сегодня единственное, что сдерживает от окончательного перехода на Chrome (или на аналогичные браузеры), это менее удобно реализованная печать бумажных документов в Chrome по сравнению с Firefox, которая все еще остается крайне важной функцией в корпоративных приложениях.
Под термином «масштабируемость» как раз и подразумевается массовость производства в сфере разработки ПО. В зависимости от специфики ПО масштабировать можно по количеству пользователей, по объему данных, по объему вычислений, по количеству разрабатываемых проектов, по скорости адаптации программного кода под внешние условия и т.п.
Ну а для поддержки и доработки кода важно качественное проектирование структуры приложения, грамотная работа со структурами данных, разумное разбиение кода на отдельные процедуры, внятное документирование кода и т.д. и т.п. При отсутствии же потребности в масштабировании грамотно написанный код вполне себе можно разместить в одном слое без всяких дополнительных абстракций.
Ведь для разработки качественных абстракций также нужно потратить определенное количество труда и разных ресурсов. В примере с домом используются ранее разработанные другими людьми абстракции (стандартный кирпич с определенными характеристиками). А что если взять пример по разработке дома из деревянных бревен (не путать с брусом), размеры каждого из которых уникальны сами по себе, а характеристики зависят от сезона и места заготовки?
Здесь уже придется разрабатывать собственные абстракции, такие как технологию обработки древесины, способ укладки сруба, выбор отделочных материалов и т.д. А это значит проектирование, документирование, обучение сотрудников и т.д. Для разового проекта это не нужные дополнительные затраты, а вот в массовом производстве домов из бревен созданные ранее абстракции помогут снизить затраты, повысить качество и ускорить сроки строительства.
Так и в разработке программных продуктов. Разработка абстракций оправдана лишь либо в случае явной потребности в последующем масштабировании программного продукта, либо в случае возможности использования разработанных абстракций в других проектах. Разработка же абстракций ради хождения по ним является запудриванием мозгов заказчикам и партнерам по разработке, которая повышает риски снижения потребительских качеств продукта, его удорожания и оттягивания на неопределенную перспективу сроков сдачи продукта в эксплуатацию.
Иначе говоря, в реальной работе нужно выбирать те инструменты и технологии, которые используют окружающие тебя люди, ну или, по крайне мере, самые профессиональные и опытные из них.
Во-первых, связывание языков программирования (PHP и JavaScript) с уровнем профессионализма пишущих на этих языках свидетельствует о низком профессиональном уровне автора и его окружения, так как современный уровень развития этих языков позволяет писать на них качественные приложения промышленного масштаба.
Во-вторых, автор не рассматривает такой вариант демонстрации неграмотной речи, как проверку навыков самого кандидата по формализации нечетко сформулированного технического задания. Это свидетельствует о том, что автор является представителем самой низкооплачиваемой категории разработчиков, которые способны только на выполнение четко сформулированных задач.
В-третьих, автор даже не рассматривает наличие не очень образованного и не очень умного начальника в качестве возможности получения опыта или карьерного роста. Это свидетельствует об отсутствии у автора здоровых амбиций и желания учиться, что может означать, что такого специалиста нужно постоянно контролировать и подпинывать даже при решении самых простых задач.
Все это свидетельствует о том, что для автора гораздо важнее не то, что нужно делать, а в каких условиях это можно делать. То есть для него важнее шашечки, а не ехать. Ну а нужен ли такой специалист в команду, каждый может решить сам.
P.S.: В дополнение картинка на тему профессионального сленга:
В планировании все наоборот. И цена, и количество являются переменными величинами, которые могут постоянной пересчитываться вплоть до утверждения плана в окончательной редакции. При этом ни количество, ни цена не могут быть быть агрегированы в лоб, так как цена является средневзвешенной величиной, а количество может иметь разную размерность, а потому сумма количеств в большинстве случаев является бессмысленной величиной (например, сложение метров и килограммов). В результате для расчета плановой суммы продаж, равной произведению количества на цену, нужно для каждой позиции предварительно рассчитать это произведение, и лишь затем производить расчет общего итога. А так как и цены, и количества продукции могут быть изменены в любой момент, то такие расчеты должны производится в режиме реального времени. То есть следствием такой схемы расчета является гораздо более высокая сложность и ресурсоемкость плановых расчетов по сравнению с фактическими при агрегации даже обычных стоимостных показателей.
Что касается расчета плана сверху-вниз, то если на каком-то уровне такая схема не превращается в планирование снизу-вверх на основании норм и цен, а представляет собой лишь подгонку детализирующих лимитов под спущенные сверху сводные лимиты, то такое планирование является обычной профанацией. Поэтому такую схему нет никакого смысла рассматривать всерьез. Ведь в процессе планирования важно не только рассчитать сводные финансовые результаты, но и понять влияние на эти сводные результаты отдельных факторов, которыми как раз и выступают удельные нормы расхода, ставки, цены, различные нормативные коэффициенты и т.п. Влияние таких факторов на сводные результаты определяется путем проведения факторного анализа, выполняемого, например, методом цепной подстановки.
Что касается уровня регламентации, то здесь важно то, что нормативная база представляет собой по своей сути качественное техническое задание, содержащие в себе не только конечные формы отчетности, но и детальную регламентацию различных учетных процессов. В такой ситуации любой разработчик способен разработать программное обеспечение для бухучета, даже особо не разбираясь в его специфике.
В процессе же планирования, в котором вся исходная нормативная база и алгоритмы расчета целиком и полностью завязаны на технологические особенности организации, для разработки качественного программного обеспечения для стороннего разработчика практически нет качественных источников информации для разработки технического задания. Поэтому сегодя любой программный продукт для планирования представляет собой либо универсальную электронную таблицу типа Excel, либо некоторый полуфабрикат, который требует доработки под специфику организации с помощью консультантов за довольно большие деньги. Плюс доработка такой специфики осуществляется с использованием языков программирования, которые не доступны для самостоятельного освоения большинством экономистов-плановиков.
На тему того, что информация в процессе планирования ходит по кругу между отделами, Вы не только не опровергли мой тезис, но и сформулировали дополнительное отличие учета от планирования. Которое заключается в том, что при учете сотрудники функциональных службы в рамках учета лишь однократно вводят информацию, за которую несут ответственность (например, заполняют фактурную часть счета-фактуры). Бухгалтерия же после этого заполняет недостающие атрибуты первичных документов. При планировании службы не просто вводят информацию, которую затем используют плановики, но и периодически ее уточняют и дополняют, причем зачастую письменно обосновывая необходимость тех или иных изменений. В результате плановики не просто обсчитывают экономические показатели по всем процессам предприятия, но и интенсивно взаимодействуют с отделами-поставщиками исходных данных для плановых расчетов.
1. Принципом отнесения данных к первичным (вводимым руками) или расчетным (вычисляемых компьютером). В учете первичными данными выступают преимущественно абсолютные значения показателей (количество потребляемых ресурсов, суммы продаж, суммы процентов по кредитам и т.п.), а в планировании — преимущественно относительные (нормы расхода потребляемых ресурсов, цены продаж, процентные ставки по кредитам т.п.).
2. Учет всегда оперирует фактической информацией, которая является максимально полной и достоверной. При этом план всегда оперирует будущей информацией, которая по определению всегда недостоверна и фрагментарна.
3. Уровень детализации в учете и планировании определяется возможностью контроля руководителей организации за качеством управленческой информации. В учете, который оперирует фактической информацией, возможен контроль на уровне каждой хозяйственной операции, оформляемой первичным документом. В планировании, оперирующим информацией о будущем, контроль возможен только на уровне укрупненных статей, так как излишняя детализация планов лишь повышает степень их неопределенности.
4. В учете в подавляющем большинстве случаев используются последовательные расчеты вычисляемых показателей. В планировании зачастую невозможно обойтись без рекурсивных расчетов.
5. Учет представляет собой строго регламентированный процесс, регулируемый нормативными актами начиная с федеральных законов и заканчивая внутриведомственными инструкциями и стандартами. Для планирования отсутствует какая-либо регламентация со стороны государственных органов (за исключением государственных учреждений в рамках бюджетного процесса), в внутри организации процесс планирования в гораздо большей степени регулируется сложившимися практиками, чем внутренними нормативными актами.
6. Учет представляет собой периодически повторяющийся и практически не меняющийся со временем процесс с временным лагом в один месяц. Планирование больше всего похоже на проект, который выполняется один раз в год (для годового планирования) каждый раз в новых условиях (факторов внешней среды) и с новыми критериями эффективности (целями высшего руководства).
7. Учет в средних и крупных организациях, как правило, разделен на несколько однотипных процессов (материальный учет, финансовый учет, кадровый учет, учет основных фондов, налоговый учет и т.п.), который ведется узкоспециализированными сотрудниками (кадровик может не разбираться в налоговом учете и наоборот). В планировании работы в рамках всех процессов выполняется одними и теми же сотрудниками, обладающими знаниями по всем планируемым процессам организации. Малые предприятия несколько выпадают из данной классификации — в них обычно весь учет ведет один главный бухгалтер, а планирование как таковое вовсе отсутствует.
Указанные факторы, несмотря на довольно большое сходство итоговых документов в учете и планировании, приводят к невозможности использования учетных программных продуктов в процессах планирования. А где это делается, там эффективность планирования в лучшем случае стремится к нулю, а в худшем — вводит в заблуждение руководство организации об экономической эффективности их собственных планов. По этой причине подавляющее большинство организаций для планирования используют MS Excel, даже при наличии у них эффективной автоматизированной системы учета.
В качестве представителя не указанного в статье класса систем, предназначенных для автоматизации системы бюджетирования и управленческого учета, можно привести платформу экономического моделирования JetCalc. На Хабре опубликованы следующие статьи про JetCalc:
1. Последовательность шагов по организации управленческого учета на платформе JetCalc.
2. Есть ли альтернатива Excel в сфере бюджетирования и бизнес-аналитики.
Например, возьмем инструкцию по эксплуатации бензопилы Husqvarna. В ней описаны и устройство бензопилы, и техника безопасности, и основные приемы работы, и техническое обслуживание бензопилы. Но наличие этой инструкции совершенно не гарантирует, что в реальном лесу конкретный лесоруб не опилит себе ногу или руку этой бензопилой по собственной дурости просто потому, что пошел валить деревья бухим (или сонным, или на нервах, или ...). Но зато наличие такой инструкции не позволяет пострадавшему предъявить претензии к производителю бензопилы для возмещения ущерба за отрезанные руки или ноги.
Если это так, то чем тогда Ваши представления о свободе отличаются от красивых проектов Обломова? Лично для меня — абсолютно ничем. В своей жизни я наблюдал сочетание абсолютной свободы в отсутствии воли и интеллекта только в виде вульгарных шествий извращенцев в костюмах проституток плечом к плечу с проститутствующими (по необходимости) политиками и проститутствующей (по призванию) богемой. Счастье, что только по телевизору.
www.anekdot.ru/id/1084968/?fbclid=IwAR0GO0EHzXZxezsohfAM6QXQttxYDK5Ktn8n3m9EzflEjczlxRorMkdXNxY
Друзья, на моих глазах запороли две перспективные компании из четырех федеральных, в которых мне довелось поработать. В лучших традициях моих рассказов, весело и с матом я расскажу как можно всадить любой перспективный бизнес за максимально короткий срок.
До веселой матершинины нужно прояснить два момента. Первый — зачем в компании нужны политики и процедуры? Вы не знаете? Чтобы их исполнять? Да перестаньте! Политики и процедуры создаются, чтобы заменить незаменимых. Это просто стадия жизни компании от хороших специалистов до хороших политик и процедур. Следующий этап жизни компании: засирание нереализуемыми политиками всего поля принятия решений, локальных ресурсов и главное — изъёбывание всем мозгов.
Второй момент — почему в ответственные моменты на ключевые позиции часто назначают мудаков? В среднем по автобусу их и так дохрена, но раньше они не могли себя проявить полностью. В критические моменты все становится очевидно.
Если перевести мою статью на английский и закинуть в google, то наверняка найдется пуля в пулю такая же методичка. Ну не могут дураки придумывать одинаковую ху… ю с точностью до ноты!
Итак, как запороть компанию!
Правило 1: снеси всех адекватных топов, но не трогай дураков. Дураки этого хода не поймут, но будут все время тебе в рот заглядывать и рассказывать всем какой гендир мудрый и вообще пиздатый;
Правило 2: прими нереальный бюджет. Даже акционеры должны ох… ть от твоих обещаний. В итоге выручка год к году +30%, расходы -30%. Бюджет должен всех разумных менеджеров бросить в мороз-понос. Слабые бюджеты для сопляков, устрой этим сучкам новый 37-ой год;
Правило 3: сократи 10-15% штата. Неси любую ересь про неэффективный балласт, тенденции ведущих компаний, автоматизацию и роботизацию. Лучше приводить в пример американские компании, там всегда липко-сладкие истории для дебилов;
Правило 4: демотивируй всю компанию пересмотром премий, соц.программ и любых льгот. Если была сотовая связь, зарежь ее для большинства сотрудников или уменьши компенсацию в три раза. Пойми — они зажрались! Кто не хочет, может искать другую работу. Ты легко наберешь на рынке свежих долбоебов из другой сферы, без нужного опыта, но преданных как немецкая овчарка;
Правило 5: сообщи всем сотрудникам, что в компании тяжелые времена. Это даст тебе еще гамму ебанутых ходов и развяжет руки;
Правило 6: парализуй перемещение и найм сотрудников. Вместе с сокращением штата это классный метод убить целые направления работы: растерять корпоративных клиентов, ключевых поставщиков, задрочить преданных менеджеров;
Правило 7: перекрои всю штатку, объедини пару дирекций, самые активные подразделения рассели в разные корпуса, желательно в разных районах города. Если система вдруг заработает, то ты молодец. Если не заработает, то эти говнюки саботируют процесс;
Правило 8: передай управление бизнесом службе HR. Запомни, шеф, эти сраные начальники направлений всегда хотят больше людей, чтобы эффективнее работать. Покажи, что эти недоумки тут не главные. Вместе с контролем численности пусть бизнес обосновывает необходимость найма кадровикам. Не путай: не HR для бизнеса, а бизнес для HR!
Правило 9: режь косты! Не сокращай затраты, а именно режь и именно косты. Под этим мероприятием можно понимать любую хрень. Покупай бензина в два раза меньше обычного, не заказывай офисные принадлежности и бумагу для принтеров. Никакой туалетной бумаги Tork! Оцинкованное ведро в углу в лучшем случае;
Правило 10: придумай ебанутые KPI. Например, «из каждого килограмма досок должно получаться два килограмма скворечников». Как? Да это не твое дело! Пусть думают и лучше работают, бездари. Могут использовать больше гвоздей или собирать со скворцами уже внутри;
Правило 11: заморозь всё перспективное развитие. Нельзя ничего развивать, когда у компании тяжелый период. Даже жизненно необходимые проекты могут подождать твоего золотого парашюта;
Правило 12: внедри новую систему отчетности. Это позволит тебе запутать руководство еще на пару месяцев;
Правило 13: тащи в контору именитых консалтеров, лучше бы из совершенно другой сферы. Если твой бизнес — не FMCG, то консалтеры должны быть именно оттуда. У них все просто: склад-полка-покупатель. А ты же так и делаешь! Всей кучей можно втирать очки до последнего.
И запомни главное, не ты плохой, просто ты гораздо умнее этого мяса. В конце концов, у тебя же есть MBA и диплом какого-нибудь американского ВУЗа, в котором ты никогда не был. Если когда-нибудь дрогнешь, вспомни, что Google переводит сотрудников на home-office, а Цукерберг обещает запускать дирижабли с Wi-Fi в пустынях. Ну неужели ты на работе не сможешь нести такую же ху… ю?!
И человек изначально рождается абсолютной несвободным. И только со временем лишь считанные единицы становятся по настоящему свободными, постепенно беря под контроль свою боль и свой страх. Для большинства же припасена красивая сказка о наличии у них свободы воли, которая разбивается на мелкие осколки при первом жестком соприкосновении с действительностью, равнодушной к чьей-либо воле.
Мысли же могут быть свободны только у людей, которые способны их самостоятельно сформулировать, а не заимствовать у других людей. Ведь свобода навязанных мыслей аналогична свободе перемещения в пределах тюремной камеры в определенное время суток.
И здесь возникает вопрос: может ли быть свободным слово, основанное на несвободных мыслях? Ответ на мой взгляд однозначен – не может. Поэтому людей, которые говорят о свободе слова, транслируя без переосмысления чужие мысли, можно в лучшем случае назвать демагогами, а в худшем – провокаторами.