Подпишитесь на новости

05.08.2021
3 ошибки в подходах программ для строительства
На сегодняшний день на рынке присутствует ряд информационных систем для строительства, которые достаточно проблематично «приземляются» на бизнес-процессы строительных компаний. Так в чем же дело? Будем разбираться…
3 ошибки в подходах программ для строительства

Программы для строительства, примеры подходов

Судя по тому, как фактически работает та или иная строительная информационная система, достаточно просто определить ее идеологию и приоритеты, а следовательно, и понять какие требования были заложены в основу.

Мы разобрали несколько ИТ-систем, представленных на рынке автоматизации строительных компаний, и которые были выведены из эксплуатации нашими клиентами. Мы решили разобраться с проблематикой и сделать выводы, в том числе и для себя.

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

Подход 1. Программа для строительства – это набор отдельных функций

В данном подходе информационная система рассматривается исключительно как набор функциональности без рассмотрения событийной модели и взаимосвязей, что очень важно в строительстве.

В итоге готовая система, выглядит (образно) как меню в ресторане, где можно выбрать любое блюдо или набор блюд.

Такая информационная система вряд ли обеспечит слаженное взаимодействие между подразделениями, событиями и самими данными. Это лишь некая фиксация формальных документов: что вижу – о том пою. Взаимосвязи как правило определены на уровне "документ - справочник", "отчет - документ - справочник" 

Событийная модель при данном подходе проста: создать/изменить/удалить.

На рынке встречается много решений/утилит, которые, например, только собирают данные с объектов и фотоотчеты без какого-либо взаимодействия со складом, планированием, финансированием исполнителей и т.д.

Подход 2. Программа для строительства — это автоматизированный основной линейный процесс и вспомогательные задачи в рамках этого процесса

Берется за основу какой-то базовый бизнес-процесс, например, от начала коммуникаций с клиентом до сдачи объекта клиенту.
В рамках этого процесса реализуется workflow, имея кое-какие ответвления (проверка, согласование).
Как говорится: «Уже немного теплее», т. к. данное решение позволит обеспечить условный конвейер бизнес-операций и уже не будет выглядеть как некое нагромождение документов, списков и отчетов (как при Подходе 1), в довесок появятся однозначные связи между документами и статусы.
Некоторые горячие головы тут же начинают автоматизацию на базе BPM-решений, но подвохи ждут впереди. 

Дело в том, что сама деятельность строительных компаний не имеет линейного характера, постоянно наступают события, влияющие на процесс и цепочку действий.
Проще говоря: бывает так: договора еще нет, сметная документация готова частично или не готова, а работы нужно уже начинать и фиксировать объемы, списания ресурсов, делать фото-отчеты и собирать исполнительную документацию. На таких нестандартных сценариях BPM-решения не являются 100% волшебной таблеткой, но безусловно могут стать некой основой.
И вопрос здесь даже не столько в классе системы (BPM или что-то иное), сколько в необходимости проработки всех возможных сценариев еще до начала автоматизации.

Здесь можно рассматривать:
  • незапланированные поставки материалов, ресурсов;
  • новые договоренности с заказчиком уже в ходе реализации проекта;
  • изменения состава смет, плана графика;
  • отмена поставки, замена;
  • изменение состава субподрядчиков ввиду неприемлемого качества работ и так далее.
Сами изменения не обязательно являются какой-то внештатной ситуацией – это скорее обычные явления в реализации строительных проектов.
При описанном выше подходе получаем частично рабочий вариант информационной системы для строительства но желательно в идеальных условиях, как говорится: до первого поворота.
Некоторые производители ПО останавливаются на каком-то более-менее однозначном локальном процессе, например планирование (сметы, ГПРы) и совершенствуют только эту понятную им область, не касаясь остальной проблематики.

Подход 3. Программа для строительства — это строгий набор правил

Заказчик транслирует тезис, что система должна пресекать любые действия, если они нарушают регламент. Например: не давать создавать документы задним числом, блокировать отгрузку на объект по тем или иным причинам, не давать списывать материалы в производство, если нет накладных, не позволять формировать заявки, если есть превышение сметного лимита и т. д.

Представим строительную информационную систему, в которой на 100% реализован данный подход, и рассмотрим пример:

На объект привезли материал со склада, а в строительной программе момент приемки на склад еще не отражен (кто-то не успел, заболел, или иное обстоятельство)

То есть, с одной стороны, в реальности наступило событие, когда материалы прибыли на объект. С другой стороны – в системе есть блокировка на приемку материалов на объект, т. к. в противном случае образуется отрицательный остаток на складе.

Что сделает начальник участка или иное ответственное лицо? Правильно, примет материал, распишется в накладной, а в строительной системе этот факт отражен не будет (система не даст это сделать) и возникнет искажение данных.

И с каждым разом разрыв с реальностью будет нарастать, а ценность строительной ИТ системы для строительства - снижаться.

Резюме

Можно выделить главные тезисы, которые желательно учитывать при проектировании программных решений для автоматизации строительства:

1.     Сквозные связи. Это только про реляционные связи на уровне БД со справочниками, но и про связи между бизнес-процессами, работами, ресурсами, объектами

2.     Обработка изменений. Необходимо ответить на ряд вопросов к цепочке документов, например,

  • что первично: смета или договор?
  • как быть, когда работы нужно начинать еще до готовности/согласования смет?
  • как контролировать и обрабатывать изменения смет уже на этапе выполнения работ и фиксации КС-6а, КС-2?
  • как обрабатывать внеплановые работы?
  • Как завершать проект досрочно по соглашению сторон с частичным выполнением плана?
  • Как отследить отмену поставок и влияние на производство работ?
  • Какая событийная модель применима
  • Процессный подход. В данном случае система рассматривается как совокупность процессов, в ядре которых лежит Проект, который в свою очередь опирается на договор, сметы, план или совокупность планов. Далее Проект обслуживается процессами: производство, финансирование, закупки, логистика и др.

То есть нужно не забывать о том, что ИТ-решение для строительства - это комплексная система, живой организм, где все процессы переплетены и взаимозависимы не только на уровне узлов, но и на уровне элементов (работы, ресурсы, люди, деньги, объекты, склады...)

Если Вы являетесь разработчиком или заказчиком ИТ решения для строительства, то вероятно Вам также имеет смысл взять эти тезисы на вооружение

Приближается Новый год!
В преддверии Нового Года и Рождества, решили поднять вам немного настроение.
Предлагаем небольшую подборку новогодних историй...
22.12.2023
Важное о встречах и протоколах
Как структурировать протоколы встреч?
Как сгруппировать поручения по тематикам и проектам?
Как сформировать отчет об исполнении поручений к ближайшей встрече?
Ответы и возможности вы найдете в нашем новом приложении Meety
14.08.2023
Как понять приемлемость темпа выполнения работ на объекте
Понимание темпа работ позволяет спрогнозировать сроки, оценить риски и принять своевременные или превентивные управленческие меры. Как определить темп и спрогнозировать сроки? Читайте продолжение...
04.06.2023
Внимание, сезонное снижение цен на лицензии
На сезон лето-2023 цены на лицензии снижены на 30% и более.
Стоимость услуг поддержки остается без изменений
29.05.2023