30.09.2004Sigurd Nes, Bergen Bolig og Byfornyelse 1 “Open Source Software” for Facilities Management

30.09.2004 Sigurd Nes, Bergen Bolig og Byfornyelse

1

“Open Source Software” for

Facilities Management


2

Goals

• Cost/benefit analysis of FM systems

• To make available a FM-system to that is powerful, flexible, inexpensive and easy to use.


3

Grad av forskning[Gunnarsson 2002]

Grunnforskning Produktutvikling Saksutredning


4

Model/Potential

• 30 % …of ”….” [Det digitale byggeri] due to reduced friction between phases/systems

• The system itself (interaction / automation / information (availability/quality))• Awareness / organizational effects

IFC - models

IFC (XML)

Planning / Project

Operational phase

( OODBMS )

Traditional FM-system( RDBMS )

CAD Expert-s

Accounting systemE-Commerce

Expert-s


5

Method

• Literature study: FM,OSS,FM-system• Role/point of view : Subjective, participating

approach; understanding is fundamental for understanding (hermeneutics ?)

• Casestudy BBB (1995 - 2004)– Cost benefit

• Measurable benefits• Intangible effects

– desirability/probability [Bjørn Lien and Øivin Bjørn] – Analytic Hierarchy Process or the Multi Attribute Utility Theory [

Tangen 1996]

• Empirical survey (this far: Disaster)

http://127.0.0.1/thesis/php/appendixes.php#Lien_1990





http://127.0.0.1/thesis/php/appendixes.php#Tangen_96

http://127.0.0.1/thesis/php/appendixes.php#Tangen_96

http://sigurd/fm-system/FDVU_front.html


6

Limitations - case

• In-house development of a commercial tenant/lease management system.

• the integration of this system with a standard commercial CAFM system

• Development and migration to an Open Source Software project with e-commerce capabilities


7

Case: BBB

• Bergen Housing and Urban Renewal (BBB):– 5000 dwellings, whereof 800 in housing cooperatives – 430.000 m2 – Maintenance budget ~ 30 mill NOK pr year – Rebuilding/construction ~ 100 mill NOK pr year – Maintenance lag ~ 175 mill NOK– 40 employees


8

BBB Maintenance

0

50

100

150

200

250

Year

NO

K

Preventive 24 46 57 105 115 117 89 91 64 67 77 161

Demand 43 50 63 93 104 107 72 75 73 80 83 0

1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003Holte 2003

All values related to 2004


9

BBB – FM Total

0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

400,00

Sum vedlikehold

Sum Drift

Sum Forvaltning


10

The software implemented at BBB

• So far – more than 22000 orders is registered in the system

• There is approximately 800 occurrence of moving throughout the portfolio per year which generates reports and workorders (initiated through the Helpdesk)

Linux web-server Mssql db-server


11


• Upside– Direct cost reduction due to licenses is 100.000

NOK per year compared to commercial systems – The integration with accounting system has

dramatically reduced the workload of manual punching

– Information is more reliable due to central stored and distributed accessable updated information

– All entities in the production environment is somehow related an subject to reports – which greatly improve the overall control.

– New features is fast and easily adapted


12


• Downside– The fact that this software as yet is not very

common – makes the company pretty depended of my welfare. However there is a vendor which is prepared to offer commercial support


13

Software architecture

configuration Metadata standards

Dynamic data

Database abstraction (API)

SO ”SO” Storage objects layer

BO ”BO” Business Object layerUI

”UI” User interface layer

XML – generating (API)

XSLT – processingWeb-server/XML/XSLT - processor

API

Compressed data (mod_gzip or mod_deflate)


14

Platform

• Windows or Linux

• PHP with XSLT

• Webserver: IIS or Apache

• Database: mssql, mysql, postgresql or oracle. (support for db transactions is very important)


15

The fm-system – core elements

Location entity actor

Virtual

concrete

Helpdesk Project->orderService

agreement

Document

Pricebook

Conditionsurvey

Customreports

Invoicehandling

TenantOwner Vendor


16

Meta database

The meta database keeps track of:• Tables• Columns (Attributes)• Relations• Generated queries• Attribute options• Inputname and help textsfor space hierarchy and entities


17

Level 1

Level 2

Level n

Column 1 Column m

•The hierarchy is configurable in both width and depth - that is: one can define as many levels as one like - and each level can also have as many attributes (of “any” kind) as one would like

•The naming of each level is free.

Attributes

Level

Location


18

Location

• Each level has a primary key - composed by the foreign key to the parent - and this levels ID. In addition - there is a “superkey” named location_code for indexing and searching across the hierarchy

location_code loc1 loc2 loc3 loc4

5000-01-01-001 5000 01 01 001

Primary key: loc1 + loc2 + loc3 + loc4Foreign key: loc1 + loc2 + loc3Superkey : Location_code


19

Location

• When querying location on a certain level - it is joined with all its ancestors to make inherited information available.


20

Location

Name Level Relation . -- Property 1 <--- Owner, part of town /-- Building 2 /-- Entrance 3 <--- Street /-- Apartment 4 <--- Tenant /-- Room 5

The relation between location-level and owner, part of town, street and user/tenant is configurable


21

Entities

• Entities is a generic class of objects that all have in common that they can be placed in a location and/or linked to other (only one) entities.

• Entities are organized in class of entitity and entity category: each entity-category is represented by their own table.

• Each entity can have as many attributes (of “any” kind) as one would like.

• Documents (files) can be linked to entities.


22

Entities: examples

• Equipment– Elevator– Fire alarm central– Cable TV– Building components– Drawings– Key system

• Reports – Condition report– Insurance damage– Elevator control report


23

Example – defining a attribute


24

Helpdesk

• The HelpDesk submodule is a hacked version of the phpgroupware's standard Trouble Ticket System application. The main differences is that the tickets are fixed to a location or entity - and that one is able to start projects and entities (i.e. reports) from a ticket - which enhance the trace-ability

• The owner a of ticket is notified by mail when the ticket is updated.


25

Helpdesk – screen dump


26

Access control / security

• All records is owned by a user – this user can grant others (groups or/and users) rights to read, edit – or delete his/hers data.

• Within each submodule (and for each entity_category) the rights is controlled by the system administrator granting rights to groups or/and users.

• The same rights can be masked (denied from inheritance)

• There is in addition three roles for approving invoices for payment.


27

Rights


28

History

• For projects, deviation and helpdesk there is logged history for :– changing Status– changing coordinator– changing Budjet– Order by email


29

Deviation

• Deviation id categorised by NS3424 :– Condition degree– Probability for worsening– Consequence

• Deviation is subjected to areas like (naming is configurable):– Safety – Aestics– Indoor klimate – Consequential damage– User satisfaction– Residential environment

• The waigt of each different areas is configurable – as basis for prioritizing (by calculated score)


30

Key for prioritizing- Deviation


31

Screendump - deviation


32

Project• A project is a collection of orders/contracts. The project is linked to a

location or entity (equipment). Projects is separated in orders/contracts that could be subject to bidding contest amongst vendors. Each order is linked to its parent project and to a vendor - and consists of a series of work-descriptions to perform and / or items to deliver.

• An order can be defined as simple as a brief description of simple tasks - or as a detailed complex tender document with a full blown deviation auditing system up per record in the contract

• The perspective of the projects is from the receiver of the product delivered

• Remaining reserve is calculated from the sum of p_deviation throughout the project

• Records is added from pricebook, NS3420 or from a template.


33

Project - structure

Project

Contract

record p.deviationContract

record p.deviation

Invoice


34

Add custom record


35

Add from pricebook


36

Electronic invoice handling

• Import of invoices– BBS files– SDV (semicolon)– Position separated– XML

• Approval based on role

• Export to payment system/budget accounting system


37

Text - multi language support

• All occurrence of text in the system is fetched from a language table – where the english version of the text is the key – and translated to the language set in the preferences.

• This approach also enables branch-jargon– Example: what the operation branch would

name ”order” – the project branch would name ”contract”.


38

TicketReport

Project

Order

Avvik

Invoice

Vendor

Originator

Supervisor

AvvikDeviation

Insurance damage

Condi

tion

surv

ey

Helpdesk - dataflow


39

Invoice dataflow

Invoice import (2)

Pre transfer for reporting (3)

Transfer for payment (5)

Order (1)

approval(4) FM-systemBudgetaccountingsystem

Vendor


40

At last

• This software is meant to be used for no fee by all that need this kind of software to lower the threshold for implementing such software