Судя по тому, как фактически работает та или иная строительная информационная система, достаточно просто определить ее идеологию и приоритеты, а следовательно, и понять какие требования были заложены в основу.
Мы разобрали несколько ИТ-систем, представленных на рынке автоматизации строительных компаний, и которые были выведены из эксплуатации нашими клиентами. Мы решили разобраться с проблематикой и сделать выводы, в том числе и для себя.
Вариантов тупиковых подходов может быть довольно много, поэтому в данной статье мы разберем 3 ошибочных подхода в проектировании, которые препятствуют успешной эксплуатации информационной системы для строительства.
В данном подходе информационная система рассматривается исключительно как набор функциональности без рассмотрения событийной модели и взаимосвязей, что очень важно в строительстве.
В итоге готовая система, выглядит (образно) как меню в ресторане, где можно выбрать любое блюдо или набор блюд.
Такая информационная система вряд ли обеспечит слаженное взаимодействие между подразделениями, событиями и самими данными. Это лишь некая фиксация формальных документов: что вижу – о том пою. Взаимосвязи как правило определены на уровне "документ - справочник", "отчет - документ - справочник"
Событийная модель при данном подходе проста: создать/изменить/удалить.
На рынке встречается много решений/утилит, которые, например, только собирают данные с объектов и фотоотчеты без какого-либо взаимодействия со складом, планированием, финансированием исполнителей и т.д.
Заказчик транслирует тезис, что система должна пресекать любые действия, если они нарушают регламент. Например: не давать создавать документы задним числом, блокировать отгрузку на объект по тем или иным причинам, не давать списывать материалы в производство, если нет накладных, не позволять формировать заявки, если есть превышение сметного лимита и т. д.
Представим строительную информационную систему, в которой на 100% реализован данный подход, и рассмотрим пример:
На объект привезли материал со склада, а в строительной программе момент приемки на склад еще не отражен (кто-то не успел, заболел, или иное обстоятельство)
То есть, с одной стороны, в реальности наступило событие, когда материалы прибыли на объект. С другой стороны – в системе есть блокировка на приемку материалов на объект, т. к. в противном случае образуется отрицательный остаток на складе.
Что сделает начальник участка или иное ответственное лицо? Правильно, примет материал, распишется в накладной, а в строительной системе этот факт отражен не будет (система не даст это сделать) и возникнет искажение данных.
И с каждым разом разрыв с реальностью будет нарастать, а ценность строительной ИТ системы для строительства - снижаться.
Можно выделить главные тезисы, которые желательно учитывать при проектировании программных решений для автоматизации строительства:
1. Сквозные связи. Это только про реляционные связи на уровне БД со справочниками, но и про связи между бизнес-процессами, работами, ресурсами, объектами
2. Обработка изменений. Необходимо ответить на ряд вопросов к цепочке документов, например,
То есть нужно не забывать о том, что ИТ-решение для строительства - это комплексная система, живой организм, где все процессы переплетены и взаимозависимы не только на уровне узлов, но и на уровне элементов (работы, ресурсы, люди, деньги, объекты, склады...)
Если Вы являетесь разработчиком или заказчиком ИТ решения для строительства, то вероятно Вам также имеет смысл взять эти тезисы на вооружение