1000 долларов тому кто сделает в Spider такой же Cash Flow как в Turbo Planner или хотя бы Excel

Купившие Spider Project и отказавшиеся от него из-за проблем с Cash Flow подтверждают тезисы изложенные в данной статье

Это очень важная статья по ключевой задаче в управлении промышленными проектами, когда кроме календарного графика самих производственных работ (СМР) автоматически составляется отчет по Движения Денежных Средств (ДДС, Cash Flow) и план закупок материалов. Задача является базовой и ей занимаются почти все как правило пытаясь ее сделать в связке MS Project + Excel или Primavera + Excel, что приводит к колоссальной трудоемкости разработки и главное обновления планов и огромному количеству ошибок.

Я снял демонстрационный фильм как эта задача может решаться в Turbo Planner и Spider Project. Точнее фильм показывает, что в Turbo Planner вы можете 100% автоматически получать Cash Flow с учетом авансов и постоплат и закупки с учетом рейсов и партий постовок, а вот в Spider Project вы не сможете это сделать даже так эффективно как можно было сделать это в Microsoft Excel. Я предложил в наших огромных группах в Facebook (7800 профессионалов)  и LinkedIn (5000 профессионалов) пари на 1000 долларов любому "Спайдермену", который сможет доказать обратное. И перчатку подобрали, но автоматический Cash Flow и закупки у лучших из лучших планировщиков на Спайдере не получилось сделать как это легко получается в Turbo. В видео я показываю сравнение со стандартным демопримером в Spider Project, но составлен так, чтобы скрыть ограничения продукта. Реальный пример в Spider я рассматривают в этой статье.

Обращаю внимание, что статья написана в стиле Пари с планировщиками-спайдерменами.

Об различии бюджетов ДДС (Cash Flow) и бюджета Доходов и Расходов для производственников

Это уже вторая редакция статьи по ответам на вопросы к ней. По вопросам производственников я понял, что нужно сначала на примерах пояснить основы бюджетирования и отличия бюджетов ДДС (Движения Денежных Средств) и Доходов и Расходов. Демоверсия проекта в составе Spider Project сделана с ошибками финансового моделирования, чтобы проще продать модель производственнику неискушенному в этом, но даже опытный планировщик в Spider Project будет делать модели иными средствами чем советует маркетинг Владимира Либерзона.

Turbo Planner в отличие от Spider Project понимает разницу между освоением СМР, выплатами, а также фактическими и принятыми объемами

Поясним на примерах. Обычная демка в Spider пытается продать как "выплаты" фактическое совершение производственных операций. Но даже опытный строитель сразу поймет, что это ни разу не выплаты денег. То что вы отлили колонну совершенно не означает, что вам за не заплатят в этот же момент. Вам за нее заплатят некоторое количество денег до начала операции как аванс и некоторое количество после как постоплата. Между начислением затрат и выплатами всегда существует разница на размер задолженностей между заказчиком и подрядчиком (дебиторская и кредиторская задолженность). В демке Spider пытаются "продать" как Cash Flow именно отчет об Доходах и Расходах (Profit & Loss) пользуясь тем, что ДДС и ДР сходятся по сумме после завершения проекта и производственник не заметит подвоха, но финансовый директор естественно заметит, что в периодах не сходятся суммы платежей.

В Spider Project пытались реализовать аналог системы платежей Turbo Planner, но решение не доделано в части постоплат, платежей в разрезе подрядчиков и главное такого  же моделирование партий закупок материалов, поэтому CashFlow неправильное если материалы идут крупными партиями

В принципе даже первокурсник Финэка отметит, что модель Spider в демке не тянет и как моделирование Доходов и Расходов, т.к. предоплагается, что раз операция совершена, то заказчик уже должен подрядчику. Естественно это даже юридически не так и грубо нарушает порядок ст. 720 ГК РФ указывающий, что заказчик должен подрядчику только после завершения приеки и собственно подписания акта. В Turbo Planner поэтому сделано моделирование актов с заказчиками и подрядчиками. Если на планировании отказ от моделирования актов еще более-менее допустим как не создающий большую ошибку, то вот при вводе факта нужно быть очень неопытным в бизнесе, чтобы считать что фактически измеренный фактический объем это сразу же долг по этим работам. Нормальный заказчик не будет принимать отдельные работы, а будет принимать сразу комплекс работ.

До октября 2014 года маркетинг Spider Project активно продвигал идею построения Cash Flow с помощью выравнивания ресурсов. Хотя математический замысел был в чем-то даже изящен, однако заложенная в него идея "равномерного размазывания денег" с путаницей между бюджетами ДДС и ДР привела к тому, что финасисты не соглашались с такими моделями и были вынуждены делать их снова в MS Excel параллельно с работой в Spider и как отмечает глава "8А-ГРУПП" Окасана Чуваева в отзыве на эту статью в LinkedIn они были вынуждены отказаться от Spider Project по этой причине. При этом довольно тревожно рапортовали на форуме MicrosoftProject.ru бывшие сотрудники Spider Project Ukraine, что им так и не удалось сделать ни одно внедрение построения Cash Flow через идею выравнивания. Попытка выяснить хоть один такой пример внедрения в головном офисе коллег из Спайдера также оказалась неудачной.

Не удивительно, что столкнувшись с потерей клиентов команда Spider Project фактически решила изменить концепт и реализовать аналог платежной системы Turbo Planner, который отображен на картинке выше и работает схожим образом, но поскольку это сделано буквально несколько месяцев назад планировщики Spider Project с многолетним опытом как Максим Боруховский на практике этим не пользуются, т.к. видят много ограничений.
Текущая "копия" платежной системы Turbo Planner повторенная в Spider Project имеет довольно много серьезных упрощений, которые часто носят фатальный характер:

1. Стандартная разноска платежей Spider Project не умеет моделировать постоплаты. Однако стандартная практика большого количества подрядов это отложенная на большой период постоплата примерно на 10% от подряда как залог по гарантии на работы.
2. Spider Project планирует оплаты по фазе целиком не понимая как Turbo Planner, что платежи нужно делать в разрезе подрядчиков. Однако разница ДДС и ДР именно на дебиторскую и кредиторскую задолженность, которая без контрагента не имеет никакого финансового смысла.
3. Spider Project до сих пор не умеет как также как платежи разбросать партии закупок материалов и материалы все также "размазаны" по по времени и предполагается их мгновенная поставка. Однако материалы около 80% стоимости и поскольку средств закупки вообще не имеется, то сам ДДС планируется Spider неверно.
4. От многих событий оплаты и поставок идут связи на СМР как опеределяющих начало операций, но генератор задач-платежей в Spider не работает вместе с шаблоном фрагмента сетевой модели для такого случая.

Если подытожить, то планировщики Spider Project считают этот функционал недоделанным и пытаются применять формулы, как описано ниже. Однако сама попытка команды Spider Project сделать "как в Турбо" говорит о том, что понимание необходимости смены базовой модели расчета Cash Flow есть, но вроде бы старейшина рынка оказался в позиции догоняющего в данный момент по функционалу совсем не для гиков, а первостепенной важности.

Сделаю еще одну ремарку. Материал написан в расчете на практиков, которые уже составляют Cash Flow (Движение Денежных Средств) по плану строительно-монтажных работ разнося их суммы по платежам хотя бы формулами в MS Excel. Если незнакомы с такой работой планирования лучше сначала посмотреть видео выше с демонстрацией и потом уже читать статью дальше иначе вам будет сложно понять многоходовый расчет от СМР к поставкам и финансированию.

Как работает схема АВТОМАТИЧЕСКОГО расчета Cash Flow и закупок 

И так, я не зря в заголовке раздела выделил, что в данной задаче главное это автоматический расчет, а ручной ввод сумм платежей. Сделать Cash Flow и закупки директивными цифрами можно (об этом ниже), но тогда модель будет проигрывать даже аналогу в Microsoft Excel собранному на формулах, который может от СМР автоматически рассчитывать закупки и платежи. На рисунке ниже рассмотрена нужна по смыслу схема расчетов на примере в Turbo Planner из учебного фильма.

Схема расчета Cash Flow и закупок от СМР в Turbo Planner

Кратко схема расчетов выглядит таким образом

1. Вы как исходные данные указываете только один показатель - укрупненный физический объем по операции.
2. Программа должна автоматически понять какие какие детальные строительно-монтажные операции нужно совершить для выполнения укрупненной операции и пересчитать от укрупненного физического объема детальные физические объемы. Отметим, что уже на этом шаге Spider Project демонстрирует беспомощность, т.к. не имеет понятия укрупненный и детальных физических объемов даже как в сметных комплексах в 5 раз дешевле.
3. После расчета объемов детальных СМР по нормам рассчитываются ресурсы и стоимости работ подрядчиков, которые законтрактованы просто от объемов (и базисно-индексный и ресурсный метод). Этот шаг реализуем и в Turbo Planner и в Spider Project.
4. Программа должна автоматически скорректировать операции закупок материалов на новый объем СМР. Ошибка моделирования "размазать" потребность в материалах по СМР, т.к. это потребление материалов, а поставки делаются отдельным графиком. Отметим, что в демопримере Spider сделана именно такая ошибка моделирования с "размазыванием" для сокрытия отсутствия функции пересчета операций закупок в отдельном графике от графика СМР. В Turbo Planner как видите по рисунку и видео 
5.  После этого программа должна понять, что появилась задолженность перед подрядчиками за работы и перед поставщиками за материалы и на размер задолженности должны 100% автоматически пересчитаться суммы платежей с учетом размеров отдельных этапов отплат, включая авансы и постоплаты. В стандартном демо Spider аккуратно обойдена проблема моделирования этапности оплат и поправок стоимостей платежей по стандартным схемам взаиморасчетов (обычно это разноска суммы договора % по этапам) и неявно предлагается "равномерное размазывание" денег под видом Cash Flow.

Как я думаю уже все догадались Spider Project не умеет пересчитывать суммы в графиках снабжения и платежей если они сделаны как положено отдельными событиями. Вместо этого предлагается в демопримере, на котором ведется обучение продукту, предлагается математическая абстракция с "равномерным размазыванием" материалов и денег по СМР, что конечно абсолютно не соответствует реальной ситуации в реальном мире. В реальном мире очень многие работы не начнутся если событие аванса не состоится или не завершится полностью поставка партии. .

Как уже отмечалось выше в Spider есть система разбивки платежей поэтому в теории нужно пользоваться ей, а не как сделано в демо. Однако в ней есть проблемы с постоплатами и платежами в разрезе подрядчиков как уже описано выше, но самое главное это выпадение п.4 по моделированию закупок материалов, т.е. Cash Flow не будет работать правильно по материалам, т.е. на 80% неправильно.

Очевидно демопример в Spider Project создан для продажи программного продукта и маскирует его проблемы, функция разноски платежей Spider имеет массу перечисленных критических ограничений. Поэтому рассмотрим как пытаются решить эту задачу опытные планировщики Spider Project как Максим Боруховский.

Прощай автоматизация даже как в Excel. Ад ручного ввода сумм платежей в Spider Project

Welcome to the Formulas Hell

На рисунке ниже приведен пример как Максим стал моделировать ситуации не как в демопримере, а уже правильно явно выделяя оплаты работ исполнителю с авансом и постоплатой (что не умеет делать и конструктор платежей  Spider Project). В качестве "отчета" Максим предложил табличку аналогичную Task Usage (Использование задач) в Microsoft Project. Но что тут важное в этом примере. Как только мы отказались от нереалистичной глупости моделирования "равномерного размазывания" денег и материалов и стали вводить отдельный платежи потребовалось их вводить вручную и постоянно корректировать вручную за изменением стоимости работ. Чтобы понять лучше эту модель давайте ее соберем в MS Project даже без Turbo Planner.

Пример в Spider Project демонстрирует неспособность продукта рассчитать платежи от СМР

Такой же пример как у Максима я собрал в Microsoft Project Standard, который дешевле Spider Project в 8 раз и как по мне модель даже удобнее в использовании. Отмечу, что жуликовата и братия планировщиков на MS Project. Пример ниже многие проходимцы титулующие себя "аналитиками" и "архитекторами" продают едва ли ни как программные продукты. Хотя делается он за 5 минут. Просто нужно завести две шкалы на материальном ресурсе "Подрядчик" со стоимостью +1 рубль и -1 рубль. Далее в Использовании Задач вывести "Совокупные затраты" (Сов. Затраты), чтобы увидеть баланс взаиморасчетов. Примерно таким же способом можно сделать остаток денежных средств. Но почему такие модели как в Spider или MS Project не популярны? Причина в том, что в таком моделировании Spider Project и MS Project с треском проигрывают самому обычному Microsoft Excel.

В Microsoft Project Standard вы можете создать такую же финансовую модель как в Spider Project без автоматизации расчетов сумм платежей от стоимости СМР

Очень сомнительно, что планировщик проекта является мазохистом и захочет без конца бегать по плану платежей и закупок и корректировать их за новыми суммами в СМР. Если планировщик использует MS Excel, то он просто свяжет формулами эти планы и все будет пересчитываться автоматически. В случае Spider Project или "голого" MS Project без Турбо такая задача становится весьма нетривиальной, т.к. вам нужна формула не в рамках строки, что делается легко в обоих продуктах, а формула между разными операциями СМР, платежей и закупок.

В Spider Project составление таких формул возможно, но по сравнению с MS Excel, где чтобы привязаться к ячейке достаточно щелкнуть, вам нужно попасть в Ад Формул На Кодах. Дело в том, что для передачи значений между отдельными операциями в графике вам нужно в Spider Project указывать коды операций вручную. При этом совершенно непонятно что делать если добавите новые операции СМР и закупок. Точнее понятно, вам придется вручную писать еще новые формулы, что примерно в 10 раз более сложно чем делать формулы в MS Excel. Чтобы не быть голословным процитирую документацию Spider Project по формулам:

Работа с конкретными ячейками

Теперь после имени поля может стоять модификатор – набор параметров, заключённых в квадратные скобки.

Пример использования: VolPlan [Code, Oper1] = 5

Эта формула присвоит значение 5 полю с кодом VolPlan в строке, где значение поля Code равно Oper1. То есть в таблице операций объёму операции с кодом Oper1 будет присвоено значение 5. 

Как видите, чтобы сделать разнос стоимости СМР по операцию с 30% авансом нужно писать примерно такую формулу:

Финансирование[Code, Аванс1] = 0.3*Финансирование [Code, Перекрытие1]

Обратите внимание, что придется забивать в модели формул Spider Project насмерть коды операции платежей аванса (Аванс1) и коды операций СМР (Перекрытие1), т.е. при вставке новых операций платежей и новых операций СМР модель формул в Spider Project просто развалится. Поэтому планировщики Spider Project как Максим и не пытаются обычно строить такие модели. 

В Microsoft Project вы не можете даже формулой передать значение между операциями, но можете это сделать через "специальную вставку" заставив на лету копировать значение из одной операции в другую. Далее можно сумму разнести обычными формулами. Поскольку кодов не нужно указывать это не такая ужасная работа "шифровальщиком кодов" как в Spider, но все равно более сложно чем в MS Excel.

Но тут спрашивается за что мы вообще боремся? У нас есть разве цель сделать Cash Flow в Spider если он делает это более трудоемко чем MS Excel? Потом даже если соорудить батальоны формул в Spider Project или MS Project мы не решаем основную проблему почему пользователи хотят сбежать от MS Excel - неизбежные ошибки  в армадах ручных формул. В Turbo Planner мы как раз решаем эту проблему выполняя расчеты своими алгоритмами, поэтому типового скандала финансиста с производственником о том как вышел кассовый разрыв в компании из-за "незаметно съехавшей формулы" для пользователей Turbo Planner исключен. Но не всем везет.

Spider Project написан умершей в 1997 году платформе Borland и отсюда проблемы с интеграцией с MS Excel по отчетам и другие проблемы совместимости

Отдельный вопрос отчеты. Как вы можете заметить даже в примере Максима он использует в Spider табличку аналогичную Task Usage ("Использованию задач") в MS Project как "отчет". Я думаю такой концепт отчетов пользователи Microsoft могут воспринять с искренним изумлением.  Это в лучшем случае таблица с исходными данными, а отчет это то что может показать таблица сводная таблица Microsoft Excel или же новые дешборды Microsoft Project 2013. Я думаю еще больше пользователи MS Project удивятся, если я скажу что аналог "Использования задач" в Spider Project не редактируется как в MS Project, т.к. Spider Project очень старая программа не поддерживает неравномерное распределение ресурсов в периодах. Например, вручную заданные плановые объемы в периодах. Принцип "равномерного размазывания" всего и вся является по шкале времени тотальным в Spider Project.

Но все же почему так получается, что Максим мучается с таблицей с данными вместо отчета как сводная таблица MS Excel с произвольными фильтрами и группировками? Почему выгрузка из Spider Project в Microsoft Excel не может сразу же формировать готовый отчет по Cash Flow и Закупкам как Turbo Planner?

Spider Project написан базе MS DOS-платформы Borland C++, которая умерла в 1997 году, т.к. Windows-приложения нужно уже писать иначе, чем просто прорисовать DOS-окошки графически

Как видите на рисунке выше даже в блокноте Windows вы можете увидеть внутри Spider Project сигнатуру его платформы Borland C++ 1996 , которая отвечает на данный вопросы почему Spider выглядит несколько несовременно в плане интерфейса пользователя и почему не поддерживается продуктом масса современных IT-технологий, включая формирование нормальных отчетов в Microsoft Excel. Изначально Borland C++ это была платформа для MS DOS приложений каким и являлся Spider. Далее разработчики Borland в 1997 году предложили последнюю версию своей платформы для портирования старых MS DOS приложений в Windows 95 и объявили, об закрытии платформы и снятии ее с поддержки, т.к. Windows-приложения устроены иначе и попытка перерисовать в Windows окошки MS DOS может быть лишь временным решением. Тем не менее, Spider Project так и остался на базе умершей в 1997 году платформы, попытка перевести Spider Project на современную платформу Microsoft .Net не удалась, т.к. у разработчиков нехватило ресурсов. Это привело к тому, что продукт стал несовместим с IT-технологиями вышедшими после 1997 года. В частности современная интеграционная технология Microsoft Excel, которой пользуется Turbo Planner вышла в первой версии в 2007 году, т.е. спустя 10 лет как умерла платформа Borland.

Такие отчеты в "серверном" MS Excel из Turbo Planner в Spider Project не построить, т.к. платформа Borland 1997 не имеет поддержки облачных и других современных технологий 

На рисунке вы видите отчет по Движению Денежных Средств, который Turbo Planner выгрузил на облачный Строительный портал для финансовой службы. Также можно сделать выгрузку на Microsoft SharePoint. Однако такие типичные радости от современных IT-технологий никогда не будут доступны для Spider Project, т.к. в 1997 году когда умерла платформа Borland C++ не существовало еще массы современных IT-технологий.

Пари на 1000 долларов с любым Спайдерменом, который сможет построить такую же модель Cash Flow и закупок как это можно сделать в Turbo Planner и MS Excel

Как я уже отмечал эта статья-пари. Я утверждаю, что вы не сможете в Spider Project построить реалистичную модель Cash Flow и закупок как можно сделать в Turbo Planner или с помощью батальонов формул MS Excel, как делают все сейчас.

Поясню почему я не считаю, что Максим смог выиграть это пари. Нужно даже не победить Turbo Planner, а хотя бы сначала "младшего брата" как MS Excel и решить следующие проблемы Spider Project, которые даже для MS Excel не проблема. Конкретно по пунктам:

1. Модель Spider Project для моделирования Cash Flow и закупок от СМР не должна использовать нералистичную фикцию как "равномерное размазывание" денег и закупок, а смоделировать отдельные операции платежей (с авансами и постоплатами). Это, к слову, Максим показал как сделать в Spider Project.
2. Расчет Cash Flow базируется на 80% на плане закупок материалов, которые не телепортируются от их поставщиков мгновенно как предполагается в демопримере Spider Project, а требуют также составления плана поставок разбитого на отдельные партии как то пытается делать с деньгами конструктор платежей Spider Project. Иными словами, полноценная модель Cash Flow в Spider Project должна иметь автоматический план поставок в разрезе партий или будет неверна.
3. Построить модель автоматического расчета сумм платежей и закупок от изменения физических объемов в СМР с учетом постоянного ввода новых операций. Максим правильно отмечает, что можно в Spider Project построить такое формулами. Опустим что это настолько трудоемко, что Максим даже не рискнул приступить к такой модели. Однако чтобы модель была реалистичной она еще должна работать если в нее добавлять новые операции СМР и платежей без написания снова новых формул заново. Такое в рамках ограничений языка формул Spider Project невозможно.
4. Показать, что существует способ построить Взаиморасчеты и Cash Flow в виде сводной таблицы Microsoft Excel включая баланс подрядчиков и остаток денежных средств, чтобы его могли принять как отчет в финансовой службе, а не как сырые данные. По этому пункту решение возможно путем выгрузки данных из Spider Project в базу данных типа MS SQL и построения уже из нее отчетов SQL-запросами. Однако даже если отбросить то, что вы должны за разработчиков Spider Project сами и за свой счет написать кусок их программы по составлению отчетов, то решение по выводу остатков денег и баланса контргантами станет весьма нетривиальными через сводные таблицы. Те кто пишут отчеты понимают о чем речь. В Turbo Planner сделан целый большой модуль, который занимается формированием остатков в периодах до выгрузки в MS Excel

Тем не менее, возможно недокументированными возможностями формул Spider Project все же можно обойти недостатки его встроенной математики. Также возможно, хотя крайне трудоемко в программировании, построить через SQL-базу такие же отчеты как в Turbo Planner, но с остатками придется очень сильно повозится.

Я уверен, что не существует планировщиков Spider Project способных решить данную задачу как это делает Turbo Planner в первую очередь из-за нереально большой трудоемкости составления автоматического Cash Flow в Spider Project без использования трюков типа "равномерного размазывания".

Если же такой эксперт найдется и покажет нам реально автоматический Cash Flow в Spider Project как в Turbo Planner и с такими же отчетами в MS Excel, то я ему заплачу 1000 долларов премии и также его имя будет прославлено всеми средствами нашего маркетинга включая рассылку на 50.000 подписчиков, а также социальные группы на 15.000 участников. Можете не сомневаться, что эта слава на половину Рунета по нашей тематике позволит Вам найти отличную и высокооплачиваемую работу помимо премиальных.

Но я уверен, господа Спайдермены, что ничего у вас не выйдет. 

Разубедите нас, если получится.

Для тех кому нужен Спайдер и Turbo Planner для выполнения задания.

Демоверсию Spider можно скачать по этой прямой ссылке.

Демоверсию Turbo Planner можно получить в группе технической поддержки продукта просто вступив в нее.