Презентовать программное обеспечение научились, пожалуй, все. Кто-то хуже, кто-то лучше. Отечественные компании с серьезными рекламными бюджетами (назовем их «айтишники с цифрой и буквой») и западные разработчики активно доносят до потенциального потребителя свои фишки. У кого бюджет поменьше, те стараются оттачивать формулировки и выращивать своего клиента. Ведь даже в эпоху насыщения мира информационными технологиями, многих представителей строительного бизнеса трудно переубедить в том, что Excel – это не инструмент планирования, а хорошая электронная таблица. Но дело даже не в этом, а в том, как разработчики программного обеспечения для строителей пытаются поймать своего клиента, бравируя знакомой ему терминологией и «правильными» словами.
Хочется поговорить о мифических формулировках, связанных с бюджетированием и составлением исполнительной документации в строительстве.
Пожалуй, каждая вторая ИТ-компания, которая преподносит свои решения как специализированные для строительства, в числе конкурентных преимуществ и функциональных возможностей ПО выделяет бюджетирование. Если перечитать рекламные тексты, складывается впечатление, что любая программа решает буквально все задачи бюджетирования. На самом деле в 90% случаев функции бюджетирования в той или иной программе от строительного производства оторваны. По сути это значит: факты отдельно, а бюджет отдельно.
Я не хочу сказать, что бюджет не соблюдается. Я говорю о том, что нет связи бюджета, финансов и строительного производства.
Давайте разбираться. Часто под функцией «бюджетирование в программе» понимается следующее. В программе учитываются все операции, например, затраты на материалы, платежи, но отдельно от бюджета. Сам бюджет никак не коррелируется с фактическими событиями. В строительстве сопоставить бюджет и факт трудоемко. И строительная компания не может сопоставить бюджет и факт.
Как известно, бюджет строится постатейно. И когда бюджет уже сверстан, разобрать, из чего складываются статьи бюджета, уже невозможно. Это известно только в момент составления бюджета. А когда изменяются, например, условия поставки материалов, заказчик переносит дату платежа, то непонятно, какую сумму конкретной статьи бюджета нужно изменить. В результате может оказаться, что в какой-то момент у компании не хватит средств на закупку материалов, заработную плату и так далее. Поэтому важно, чтобы программа могла (естественно, по команде сотрудника финансовой службы, а не полностью автоматически) сама пересчитать бюджет, когда наступившее событие или его отсутствие принципиально влияет на исполнение бюджета.
Подготовка исполнительной документации – это обязательная процедура, пожалуй, для каждой строительной компании. И, конечно, немало разработчиков хотят предложить свои решения. Ведь процедура работы с журналами, документами, актами – сложная и рутинная. И здесь разработчики грешат тем, что сильно упрощают собственное видение ситуации. Казалось бы, ну что может быть особенного в программе для заполнения исполнительной документации? Бери и заполняй, выводи на печать. Но и тут есть масса «но». Пробегусь по примерам.
Итак, при подготовке исполнительной документации, в частности, журнала входного учета и контроля материалов, необходимо к каждому материалу прикладывать актуальные сертификаты. И контролировать, не истек ли срок их действия. Ведь поставщик прикладывает сертификат к каждой новой партии материалов. И со временем скапливается стопка сертификатов на материал или электронные отсканированные копии. Каждый раз при подготовке исполнительной документации нужно подбирать актуальный сертификат. И программа для составления исполнительной документации должна уметь подобрать его автоматически.
Кроме того, данные о материалах еще встречаются в различных документах (например, в актах скрытых работ), которые готовятся не на старте строительного производства, а во время проведения работ. То есть, во времени акты и журналы разорваны. В этом случае, в идеале должно быть так: сотрудник формирует акты скрытых работ в программе, указывает материалы, а перечень сертификатов должен «подтянуться» из журнала.
Далее. Словосочетание «автоматическое заполнение форм» может означать что угодно. К примеру, наличие бланков в программе, которые все равно нужно заполнять вручную, тоже подходит под эту формулировку. А нужно копнуть чуть глубже. Возьмем элементарный пример. В большинстве форм шапка и подвал повторяются. Какие-то подписанты добавляются, удаляются, но есть те, что дублируются из формы в форму. В идеале должно быть так: на первой форме заполнены подписанты, а если и в другой форме встретится тот же подписант, то он автоматически добавится в нее. Тоже нужная функция. И тоже почти не реализованная.
И еще: на практике форм документов и журналов в строительстве сотни, а то и тысячи. В некоторых же программах форм может быть от силы пять. При этом разработчики говорят, что их программа «готовит исполнительную документацию». При этом за «программу» выдается дописанная таблица Excel.
Теперь об умалчивании. Вопрос о необходимости импорта смет в программу для ведения исполнительной документации вообще чаще всего не поднимается. И действительно, для составления исполнительной документации вся смета не нужна. Нужен список отдельных работ, но из сметы его получить удобнее и быстрее, чем набивать вручную или копировать выборочно. А, к примеру, для журнала КС6-А полезно видеть и стоимость, и объемы работ из сметы. Вряд ли удобно при заполнении актов скрытых работ, испытаний набивать название работ руками. Названия работ для различных актов проще выбрать из сметы, чтобы они автоматически подставились. А после импорта сметы должен подставиться еще и перечень исполнительной документации по каждой работе. Здесь же программа должна показать, какая исполнительная документация уже создана, а какая нет. В идеале: видеть в одном месте, какая исполнительная документация по каждой работе из сметы уже создана, а какой еще не хватает.
Напоследок, хочу обратить ваше внимание и на то, что часто слова «производство» и «строительство» разработчики ставят в качестве тождественных. И это тоже уловка. Обычное желание кого-то зацепить. Конечно, строительство – это производство. Но не типичное, не конвейерное, не серийное, а специфическое. Разработчики программы для производственных предприятий часто пытаются выдать за решения для строительных компаний, но, несмотря на термин «строительное производство», эти программы не годятся для автоматизации учета.
Даже если разработчик говорит, что с помощью его продукта автоматизировано множество производственных предприятий, это совсем не означает, что успешно будет автоматизирована хоть одна небольшая строительная компания.
Под автоматизацией в данном случае я понимаю связь данных для заказчика, подрядчика, исполнителя, ведение укрупненного или детализированного учета, контроль выполнения работ на участках, формирование внутрифирменных нормативов, планирование выполнения собственных работ, возможность ведения учета для специалистов отдела снабжения именно строительной компании, а не учет звонков, контактов и фиксацию бухгалтерских данных.
Формулировок-ловушек у ИТ-компаний значительно больше. Но пока предлагаю подумать над теми, что я привожу в качестве примера.
© АЛТИУС СОФТ, 2018
© Издание 12NEWS (ИП Маринин А.Л.), 2018